posted by
janrinok
on Wednesday December 24 2014, @02:59PM
from the 'probably-not-worth-the-effort'-someone-once-thought dept.
from the 'probably-not-worth-the-effort'-someone-once-thought dept.
Dealbook/NYT : Neglected Server Provided Entry for JPMorgan Hackers
The computer breach at JPMorgan Chase this summer—the largest intrusion of an American bank to date—might have been thwarted if the bank had installed a simple security fix to an overlooked server in its vast network, said people who have been briefed on internal and outside investigations into the attack.
Most big banks use a double authentication scheme, known as two-factor authentication, which requires a second one-time password to gain access to a protected system. But JPMorgan’s security team had apparently neglected to upgrade one of its network servers with the dual password scheme, the people briefed on the matter said. That left the bank vulnerable to intrusion.
This discussion has been archived.
No new comments can be posted.
Neglected Server Provided Entry for JPMorgan Hackers
|
Log In/Create an Account
| Top
| 23 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(Score: 2) by kaszz on Wednesday December 24 2014, @03:12PM
Lesson: Keep an inventory of active equipment on your network and disconnect everything that isn't verified to be alright?
(Score: 5, Insightful) by mechanicjay on Wednesday December 24 2014, @04:08PM
The lesson learned is that retrofitting this kind of stuff into an existing network is hard. Having rolled out a 2-factor auth system last year on a much smaller network, the number of variables and potential back doors is astounding. You can approach 100% confidence in complete coverage, but only asymptotically. An operation the size of JP Morgan, would be exponentially more difficult to ensure coverage and hence that much more difficult to ensure the last 1% of coverage.
My VMS box beat up your Windows box.
(Score: 3, Insightful) by Blackmoore on Wednesday December 24 2014, @04:20PM
See; this is one of many reasons why everyone should support breaking up the big banks into smaller more manageable parts.
IT support alone would have to be managed by more groups of trained staff - more eyeballs - (and more paychecks, this isnt all about eliminating threats) While making the banks more nimble, and less destructive to the economy when they fail.
(Score: 1, Funny) by Anonymous Coward on Thursday December 25 2014, @01:45AM
good luck with that...
(Score: 4, Funny) by Marand on Thursday December 25 2014, @02:25AM
That sounds suspiciously like fragmentation, and if there's one thing I've learned from Linux distro discussions online it's that fragmentation is bad. Choice is horrible and so are you for suggesting otherwise! What are you, some kind of bank terrorist? Think of the children!
Oh, um, almost forgot an important pillar of internet and political arguments, so here we go: SOCIALISM!
(Score: 2) by Tork on Thursday December 25 2014, @04:00AM
That sounds suspiciously like fragmentation, and if there's one thing I've learned from Linux distro discussions online it's that fragmentation is bad.
Heh. Yeah, you didn't learn as much from those discussions as you think you did.
🏳️🌈 Proud Ally 🏳️🌈
(Score: 3, Funny) by Marand on Thursday December 25 2014, @07:17AM
Heh. Yeah, you didn't learn as much from those discussions as you think you did.
Seriously? Damn, I thought I had piled enough obvious sarcasm and unrelated crackpot comments ("think of the children! terrorism! socialism!") into my joke that nobody could possibly take it seriously.
I think Santa's going to be leaving a woosh in your stocking for Christmas. ;)
(Score: 2) by Tork on Thursday December 25 2014, @08:18AM
🏳️🌈 Proud Ally 🏳️🌈
(Score: 2) by Marand on Thursday December 25 2014, @08:54AM
haha. Just blame the egg nog ;)
Speaking of, merry Christmas (or equivalent) to you and anyone else reading.
(Score: 4, Informative) by doublerot13 on Wednesday December 24 2014, @03:32PM
There is and always will be non-two factor security solutions that do just fine to withstand attacks. There is a spectrum of options short of two-factor that this server obviously did not exercise. The simplest being single-factor with rate-limited login attempts.
(Score: 2) by kaszz on Wednesday December 24 2014, @03:46PM
And if the login process suffers from a stack smashing vulnerability. Security is moot anyway ;)
(Score: 4, Informative) by mechanicjay on Wednesday December 24 2014, @03:59PM
TFA said it was a case of stolen credentials. Rate limiting doesn't work if you get it right on the first try...
My VMS box beat up your Windows box.
(Score: 1, Insightful) by Anonymous Coward on Wednesday December 24 2014, @04:30PM
No amount of factors will work when one or both sides of the handshake has shitty security.
(Score: 2) by Freeman on Wednesday December 24 2014, @04:35PM
Assuming that someone has your credentials, even with 2 factor authentication, wouldn't it be simple enough to login anyway? What's stopping the user from having their password be Passw0rd and their 2 factor authentication password being Passw0rd2? I do recognize that 2 factor authentication with your mobile phone would be a fair bit more secure, but for various reasons I wouldn't want to give my Phone Number to just any random site. I don't mind my bank having my Phone Number, but I do mind giving my Phone Number to just any company. 2 factor authentication might not make any difference depending on how they got your credentials to begin with.
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
(Score: 5, Informative) by egcagrac0 on Wednesday December 24 2014, @04:55PM
That's not two factor authentication. That's two layers of single factor authentication. It's not any more secure.
Two factor authentication is based on two distinct things - typically, something you have and something you know.
The typical routes for two factor authentication I see are either an MFA system (like sending an authentication code to a mobile device), or a cryptographic hard token (like an RSA SecurID authenticator, changing code every minute or so). These would typically be combined with a PIN or password (something you know).
The second factor is almost always a one-time code. I know that when I use my authenticator, if I need to log in to another system, I need to wait the 30 seconds until the code changes, or it doesn't work.
(Score: 2) by Adamsjas on Wednesday December 24 2014, @08:23PM
This.
And there are two factor packages for linux available now (at least in the distro I use). One leverages the Google Authenticator app, and the other uses the Yubico usb "key". Right now both require access to a third party, so no good when the network is down. They use pam plugins, and pre fetch some form of oath key, and obtain an number (via encrypted link) and you must then key that number in either by the usb key (acts like a keyboard), or the google authenticator app.
The high end Yubico keys ($75) can be used stand alone, but I don't think this is implemented yet.
The google authenticator is cheap and easy to deploy. But some people don't like having Google involved at all.
(Score: 5, Informative) by frojack on Wednesday December 24 2014, @08:34PM
Actually, that is close, but not exactly right as to how the Google Authenticator actually works.
See: Short answer
http://security.stackexchange.com/questions/35157/how-does-google-authenticator-work [stackexchange.com]
Longer answer
http://garbagecollected.org/2014/09/14/how-google-authenticator-works/ [garbagecollected.org]
And it can work even in airplane mode, because the app, as well as the pam-plugin remembers the last time-key for each user, and plays that time forward even when no internet connection exists. So you can still authenticate without an internet connection, and further you don't need to have google involved at all.
There are at least two different github projects for Google Authenticator, and also for the Yubikey.
No, you are mistaken. I've always had this sig.
(Score: 3, Informative) by frojack on Wednesday December 24 2014, @08:44PM
Oh, I forgot to add, I STRONGLY recommend you use two-factor authentication on your Gmail Account (if you use any google services).
Its painless, and easy. And it isn't troublesome at all. Just do it. https://www.google.com/landing/2step/ [google.com]
Apple and Yahoo too: https://www.yahoo.com/tech/how-and-why-to-turn-on-two-step-verification-for-your-96544144259.html [yahoo.com]
(Apple as of this writing still does it wrong, using two-factor to only protect SOME things.
No, you are mistaken. I've always had this sig.
(Score: 3, Informative) by francois.barbier on Wednesday December 24 2014, @11:05PM
Something like this [wikimedia.org]
You put your card (something you have) in the reader, enter the pseudo-random challenge given by your bank website, then your PIN (something you know) and then you enter the response on the website.
You validate every (batch) of operation(s) with a similar method, with the amount in the challenge, so there's no reuse.
(Score: -1) by Anonymous Coward on Wednesday December 24 2014, @05:06PM
We love Soylent News.
Test, test, test.
Please mod this down.
(Score: -1, Offtopic) by Anonymous Coward on Wednesday December 24 2014, @05:16PM
I want a cookie!
Another cookie?
(Score: -1, Offtopic) by Anonymous Coward on Wednesday December 24 2014, @05:18PM
Anothertest moo
(Score: 4, Insightful) by iamjacksusername on Wednesday December 24 2014, @05:18PM
I think anybody who works in IT knows what the story is... multi-factor authentication is not always practical, especially on core, non-customer facing systems. Most of these systems need to be serviceable when they are in some failure mode so we protect the system in other ways. E.g., the remote management controller is only accessible via the management vlan and only authenticated IT users have access. In that scenario, authentication is multi-layer not multi-factor. Without knowing their procedures and the precise way the credentials were used, it is difficult to say how the breach actually occurred.