JP Morgan Breach Tied To Two-Factor Authentication Slip 71
itwbennett writes The attackers who stole information about 83 million JPMorgan Chase customers earlier this year gained a foothold on the company's network because a server reportedly lacked two-factor authentication, despite the company's practice of using two-factor authentication on most of its systems. The story, reported in the New York Times, echoes the warnings of security experts over the years that the breach of a single server or employee computer can put an entire network at risk.
Re: (Score:2)
Re: open source 2 factor authentication? (Score:4, Interesting)
Google Authenticator is an open source, easy to use TOTP (and HOTP) implementation which is not bad at all. The pam module is decent, and the smart phone (androit, ios, and blackberry support) client's QR Code enrollment is very convenient. Because [TH]OTP are standards, it's compatible with any other implementation of those standards, such as http://www.nongnu.org/oath-too... [nongnu.org] and the Yubikey tokens.
Personally, I use the Google Auth client with pam_krb5 / mit kerberos using a custom preauth plugin with totp keys generated by oath and stored in an LDAP backend. It's pretty neat. I mostly went with TOTP because that allows me to more easily pre-generate keys for automation jobs, btw.
Re: (Score:2)
TOTP? Top of the Pops? [wikipedia.org]
Re:open source 2 factor authentication? (Score:4, Insightful)
Google Authenticator is based on an open protocol. I can use Google's app, Amazon's, a number of various third parties, both open source and commercial available on the store/repo.
Server-side, I can use the protocol on most Linux distros, there are ways to use it with Windows, even ESXi nodes can have this added in as protection.
Yes, it might be Google code, but it is open source.
Now, RSA's SecurID is a different beast. It is a closed source system, with special servers and seed codes requires. Its advantage is that it is time tested, virtually everything supports it (MS has had hooks for ACE servers since Windows Server 2000), and it has the FIPS/Common Criteria/etc. certifications which help when audit time comes around. However, it doesn't come cheap.
Re: (Score:3)
https://github.com/google/goog... [github.com]
These are the PAM modules that one can build and configure for any OS that uses this mechanism for authentication.
Re: (Score:1)
Banking IT (Score:2)
Re: (Score:3)
History tells of banks in financial crisis due to the general population not trusting them, fast forward to today and the general population still doesn't trust banks.
They prove time and time again that they aren't responsible enough to be trusted with other peoples money.
Re: (Score:1)
Serious question: So what?
If you have better ideas maybe you should try them yourself or at least put them out there for others to try. If not then I guess you're just complaining to hear yourself talk.
Re: (Score:2)
Try regulation that includes criminal penalties including jail time in blue collar prison.
Let me guess regulation bad... banks are people!
Re: Banking IT (Score:1)
We already have regulation, what we need is jail time for the dimons and such who are supposed to be too big to fail.
Just as they prosequeted a bank in Colorado, prior to 2000, they can do it now. Remember these folks also handle retirements, civic bonds, and other tools of the people, they should be held to a higher standard.
Re: (Score:3)
They prove time and time again that they aren't responsible enough to be trusted with other peoples money.
And overall they're still the least irresponsible with it...
Re:Banking IT (Score:4, Interesting)
Re:Banking IT (Score:4, Insightful)
I will differ there. The general population may not trust banks on one level, but they will keep their money in them. If the population truly didn't trust banks, precious metal prices would be spiking, and various ways of securing physical assets would be hawked from every street corner, the more amusing will be the ones, saying "just store your stash with me".
The population gripes about banks, but when the rubber meets the road, the money still gets deposited in the checking account come payday.
Re: (Score:3)
The public trusts the banks to the extent government backstops the banks. The FDIC insurance will cover up to $200K if the bank goes bye-bye. And even if the public didn't trust the banks, they surely wouldn't trust Ma and Pa Kettle's Valu Metal Ingots with the genuine look of real gold.
Re: (Score:1)
It's better than the retailers at least. They actively disable their security systems.
Why the banks support a standard 2 factor system? (Score:5, Interesting)
Why can't they introduce two level log-ins for customers? First level log-in should be read-only, without any ability to modify anything. If you really want do a transaction, create a second level password. E*Trade used to have the system of "trade passcode" to be entered for doing actual trade, and the regular log in will only let you browse positions, balances, and set up alerts/watch lists. They took it away!
It figures, if they are that careless with their own servers, they don't give a rats tail about the customers security concerns.
Re: (Score:3)
Do you understand that using a single RSA style dongle for multiple places is a huge risk? We have standards based ways of doing this, but that does not get RSA a massive paycheck or somebody else that is huge on the hook should it fail. Hell phones are actually getting better at this putting those keys in internally hardened hardware, it's not as secure as a hard token but prevents most we got the keys to the kingdom attacks.
Re:Why the banks support a standard 2 factor syste (Score:4, Insightful)
Do you understand that using a single RSA style dongle for multiple places is a huge risk?
If you have an infinite number of systems to log into, how many dongles is optimal, and how do you keep track of which dongle to use with which system? Where do I keep these dongles? My pocket is already uncomfortably full with a keyring with 4 keys and a fob on it. My other pocket has a smart phone.
Re: (Score:1)
Depends on the cardinality of the infinity in question. If you begin life with one dongle, ignore that one for purposes of later calculations.
As this is a variation of one of those infinite pigeonhole problems, the first essential stage is to calculate a finite but abundant set of potentially infinite sets so the rest of the calculation can be done with finite but absurd quantities rather than actually infinite quantities. While the rational guide of subset construction would probably be to sort your syst
Re: (Score:2)
Use a soft token, store as many seeds and OTP's are you like. The a reason RSA tokens only have one seed is they get $$$ for each one adding some buttons to scroll up/down is a very minor security risk to make it much more functional. Modern phones are putting the seeds in hardware vaults, not quite as good but a decent trade off.
Re: (Score:2)
Taped to the monitor, right next to the sticky note with the username/password!
Re: (Score:2)
Do you understand that using a single RSA style dongle for multiple places is a huge risk?
It's not a huge risk if you're simply using the dongle as a second factor.
Re: (Score:2)
Yes it is as your using the same seed. An attack that breaks e-trade's security can then give them the seed for your bank etc etc. Software tokens make having many seeds trivial, it would be trivial to do the same for hardware tokens to some extent.
Re: (Score:2)
Still well within the confines of acceptable risk. Now, if you're personally being targeted, then that's another conversation.
Re: (Score:2)
It's nice that you think you've managed to define a rigid standard of what risk is acceptable to everybody, but I'm not sure that's actually true.
Re: (Score:2)
I wouldn't call it a rigid standard by any means. I think of it more like common sense. I'm not accounting for those that are typically more paranoid than most.
Nothing about security is absolute; it's all about risk management. Sure the impacts are huge here, but what are the likelihoods? When protecting yourself (digitally or physically), everyone takes a reasonable approach and draws the line on what is acceptable to them. In this specific case, if your second factor is compromised, your first factor
Re: (Score:2)
Or you can save the expense and skip the second factor altogether--which is an acceptable risk for almost everyone.
Side note: a second factor token isn't buying much for the attacks we're seeing in the real world. (Compromised endpoint; and no, it doesn't take personal targeting for someone to go active once a user on a compromised host has been identified as using a bank with a scripted attack pattern.) What you really want to stop theft in that scenario is an out of band channel, like SMS confirmation. Bu
Re: (Score:2)
>Yes it is as your using the same seed. An attack that breaks e-trade's security can then give them the seed for your bank etc etc.
You're making overly broad assertions.
There are plenty of protocols that can use a single hardware token in multiple places securely. By using a ZKP [wikipedia.org] for instance.
By 'seed' I assume you are referring to the time based RNG where you type in the number from the dongle. We have better ways.
Re: (Score:2)
Last I checked RSA is using a seed in their hardware tokens. That was what the debate was about and thus the assumptions relate to a RSA style seed based token not some other theoretical device.
Re: (Score:2)
Do you not realize the only difference in the singles is the seed numbers to get started with?
I use Google auth with both Google and Dropbox. It shows two different numbers( more actually as I have multiple google accounts).
The algorithm is open so people can study it. Back doors can be found and published. Why can't banks use stanardised and tested instead of closed systems with back doors?
Re:Why the banks support a standard 2 factor syste (Score:5, Informative)
That said, RSA-fobs(or house-branded devices based on the same system) aren't actually something that would be trivial to share between organizations.
The RSA fob works because it is initialized with a given seed value at a given time. Every minute it performs a hash operation that provides enough output for the on screen numeric sequence along with the input for the next hash operation(if memory serves, it is reasonably well established that it is either impossible or computationally impractical to derive the internal state from knowledge of the screen output alone, even if you have many samples).
In order to enroll a fob in your authentication system, your auth server needs to know the seed and the initialization time. It can then run N rounds of the algorithm(based on the amount of time between initialization time and current time) and determine what should be displayed on the screen(sometimes allowing for a few minutes of slip, depending on how accurate the RTCs are believed to be), If you want Company B to use Company A's token, either Company B needs to pass every auth request to Company A for processing, and accept the result, or Company A actually has to send Company B the seed an initialization time for your fob(an operation that opens up certain obvious security concerns).
The RSA fobs are pretty cute(if it weren't for the fact that RSA stores all the seed values and times, and managed to get them stolen at least once), in that they require absolutely no communication between the fob and the auth server, ever; but they do suffer from the weakness that the data needed to validate a fob are also the data sufficient to clone a fob, which makes sharing a single fob between multiple entities pretty awkward.
Irrelevant -- many banks use non-RSA fobs (Score:1)
It's fairly clear from your response that you have experience in setting up in-house, corporate systems ... and not customer-facing systems.
RSA's pricing model is simply unsustainable when scaled up for customer use which is why alternative tokens from providers like Symantec are used by many/most brokerages and banks which do offer token-based two factor authentication. Those tokens are often designed specifically to allow enrollment into multiple security systems https://idprotect.vip.symantec.com/learnm [symantec.com]
Re: (Score:2)
That said, aren't all non-connected tokens(like the Symantec one you link to) going to have the same fundamental limitation
Re: Why the banks support a standard 2 factor syst (Score:1)
So you're saying you don't have to jingle a Google dongle?
Re: (Score:2)
The best system I've seen, in theory, was IBM's ZTIC. You can make a bank transaction, but it wouldn't go through until you confirmed it on the keyfob, and the keyfob used an independent link to obtain the amount of cash, and where it was going to, to protect against a compromised browser.
The downside was that the device required special drivers, so it only functioned in Windows.
With 3G radios so cheap, why not a relatively cheap device that not jut works as a SecurID dongle, but is used with a layer of en
Schwab has plenty of worse security issues (Score:1)
Schwab has plenty of more glaring security issues than just making it hard to enroll a compatible token you already have. http://www.jeremytunnell.com/posts/swab-password-policies-and-two-factor-authentication-a-comedy-of-errors [jeremytunnell.com]
Backup confirmation from a non-blog site if you want http://arstechnica.com/security/2013/04/why-your-password-cant-have-symbols-or-be-longer-than-16-characters/ [arstechnica.com].
You'd be surprised how many other brokers were still doing the same bone headed crap (storing only first 8 chars of passw
Leaking Data - Bozobank (Score:1)
Re: (Score:2)
Here is some info I'm posting from the breach.
BANK OF BERNE Warez--slow 3.0, probe 10.0, armorall 1.0 Other stuff--Ok,
here's one you'll really like. What you do is read the messages and find out
about account number 121519831200. You use the transfer funds option to
transfer the funds to your account in the Bank of Zurich Orbital. Here's the
info you need to do it:
Bank of Berne account - 121519831200
Credit transfer authorization code- LYMA1211MARZ
Bank of Zurich link code- bozobank
YOUR account at Bank of Zurich-712345450134
You can transfer funds to your account at BOZOBANK. Be careful, there's some new AI's in cyberspace.
You missed a step.
Not a magic bullet... (Score:2)
Two factor authentication only provides any level of protection against a specific type of attack (ie guessed/harvested user accounts), and even then is often not infallible.
In a typical organisation the normal user facing clients (eg desktop machines) may require two factor, but the underlying network protocols are still using the same authentication they always have, so while you can't go in the front door through a local workstation login you can attack other devices at the network level. People frequent
Re: (Score:2)
If two factor auth can be handled by an app, or even a dongle, how much additional protection can it really provide?
Re: (Score:2)
It also raises the question, assuming the systems were UNIX based, why not just use RSA keys with SSH? The downside of this is if the bad guy grabs the private key from a compromised machine, game over... but without access to a client and private keys, this will stop a brute force password attack cold, since the attacker wouldn't get past the initial handshake, and with a utility like Fail2Ban or SSHGuard, repeated attempts can be blocked or throttled.
Re: (Score:2)
Which brings up the question, was the lack of two factor authentication actually a factor in this particular breach, or is it something that is simply being tacked onto the story?
If two factor auth can be handled by an app, or even a dongle, how much additional protection can it really provide?
It's being tacked on. If there was one factor auth and the auth failed, then it raises the question why did the auth fail? Was it weak in some way? Hypothesizing that two factor auth would have fixed it in the style of "Well duh, didn't they know to use two factor auth" is just plain overreaching and wrong. There are any number of authentication schemes of different types. You can't judge any of them without first having an idea of the capabilities of the adversary.
Re: (Score:3)
Well, sure if someone finds an RCE all bets or off. Its also as you say true that at the network layer in many (probably most cases) the authentication is the same. Two factor on Windows networks is a great example, it does little to stop pass the hash attacks, for example. Internal threats will always be a problems because they have access to lots of intelligence about the target and they have access to a large attack surface.
On the other hand two fact is a very strong control against external threats.
Re: (Score:2)
Two factor authentication is more geared for the edge, be it allowing someone to log in from home, or perform a transaction across the Internet.
On the corporate LAN/WAN [1], 2FA shouldn't be needed. Instead, RSA keys for SSH, IPSec with AD, an internal PKI with SSL/TLS, or other means should be in use. There are too many diminishing returns having it in the core of a company unless there is a good reason (different division, etc.)
The one exception might be having 2FA to be used when accessing a VDI or a C
Re: (Score:2)
[1]: Assuming a private VPLS
VPLs are by definition public.
No loss at all (Score:1)
It was said many times before. Nothing substantial was lost.
80 or 100 million of people. It does NOT matter. They are just means to make a profit. People in corporate world don't count.
As a JPMC vendor, this BLOWS (Score:1)
The organization that I work for is a third party contractor to JPMC.
Their risk management team has been up our ass for YEARS about implementing two factor authentication for the systems that we host for them. But some how a critical internal system managed to slip through the cracks? Bullshit. I have seen how that organization works. There is no way that any less than half a dozen people signed off on the risk associated with not having two factor auth enabled on that system.