Slashdot Mirror
JP Morgan Breach Tied To Two-Factor Authentication Slip
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.
It's not their money why should they care?
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.
I am Bennett Haselton! I am Bennett Haselton!
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.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
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... 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.
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.
No sir I dont like it.
Quite a few of the 'security' arrangements in financial areas make it abundantly clear that they suck because you don't really matter (this goes triple or worse for anything involving credit reports).
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.
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...
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.
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. Most orgs, even large ones now days can get their attack surface down to handfuls of web servers and vpn devices. Its mostly true that web servers themselves are relatively well hardened now days. While Apache still provides us a with the DOS attack vector of the week, I have not seen an Apache specific RCE in a long time; ditto for IIS although it looks like one *might* have been possible before the recent schannel patches. So that leaves all the vulns in the application frameworks and applications themselves to exploit.
Basic advice:
Separate your DMZs one for your home page public information, rule 0 of your firewall policy separating your internal organization from those hosts is allow only inbound {inside} -> {dmz} connections for content pushes / management. Never allow those hosts to open a socket to the inside themselves, ever. Rule 1 is the inside is only allowed to connect on handfull of specific ports that you IPS/IDS the hell outa.
You next DMZ is where you handle accounts, shopping carts, etc. That one obviously is going to have to have some well defined communication with the inside, but rule 0 here is none of the external services are un-authenticated. The only thing anyone should be able to get here without authenticating is the authentication prompt. If you can manage to code up a login page / prompt without introducing a major vulnerability you'll probably be okay; or if you are ow3d post authentication you know who you can sue.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
Compared to whom?
I am Bennett Haselton! I am Bennett Haselton!
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.
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.
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.
https://github.com/google/goog...
These are the PAM modules that one can build and configure for any OS that uses this mechanism for authentication.