Quote:Original post by sam_hughes

It wasn't fine for Cake Poker. It's a one-time cost to learn your way around a part of OpenSSL, and it's worth doing. You might as well make the other guys an easier target.

The first requirement for breaking some system is adequate interest. Spending days or weeks before the product even exists is wasted time. And context - poker and gambling in general have historically had perfect correlation to crime rates - they are magnet for all sorts of crooks, even digital ones.

It's simple economics and risk management. Further down the same post:

Quote:At that point, hire someone to build secure authentication.

The above may include up-front funding. But in absence of all of those, security is simply an afterthought. And pragmatically - how many products fail because of security breach vs. how many are never finished vs. started?

Finally, for unfunded/indie/hobbyst the advice to "learn something" is a fallacy as anything else. Adding better cogs into security machine statistically reduces chances of an incident - but important security breaches go against the odds by exploiting just one single weakness. Naive security improvements merely reduce surface area for trivial and script kiddie attacks.

So you have your biggest, baddest, slowest hash. How will you know that database was stolen in the first place? How will you know that users aren't exposed to a trojan? That your page/service isn't being hijacked or spoofed? And if it does happen, how will you handle it? How will you respond to zero-day exploits? Using some library is fine, but exploits exist everywhere, from OS to servers to XSS.

Hash is a technical detail. Make it virtual function, replace as needed. Focus on rest of the system instead.

Which is why, if security matters, you need a dedicated specialist. Programmer security is just as bad as programmer art. But at least everyone will tell you your art sucks. With security you'll find out 2 years later when your database will have 30 seeds on pirate bay.

Quote:Original post by hplus0603
Those are some pretty hard words, especially considering that most of your suggestions are repeats of what's been said here already (like, "use SSL/OpenSSL, don't roll your own, etc").

It's a lot easier and safer to say that and repeat a few things than to leave it up to the reader to decide what and what not to ignore.

Quote:

Quote:Another way (which I recommend, simply because people who know better told me to) is to use bcrypt, based on Blowfish

And after your initial hard words, you say this? That's interesting.

Blowfish is old hat. A strengthened version of Blowfish was proposed for the AES cypher, but in the end, Rijndael won out. Thus, no matter what else you do, you're probably better off using AES rather than Blowfish.

The details of how bcrypt works were not explained, so maybe you could be excused for arguing with this. It was never recommended that you use Blowfish on your passwords. The recommendation was to use bcrypt. bcrypt is not Blowfish, it's a hash function with an adjustable computational cost, that is based on Blowfish. See http://www.openbsd.org/papers/bcrypt-paper.ps for more details. The man pages and PHP documentation for crypt use the word "Blowfish" which is why that was mentioned at all. AES and Blowfish do not make message digests.

Quote:This is cryptographic common sense.

There is no such thing as cryptographic common sense. (Oh ho ho, that was dramatic! You should put on a cape before saying something like that.)

Quote:

Quote:Second, if you're storing hash(salt + password) on the server, then after the hacker has stolen your backup tapes, he can easily compute HMAC(challenge + hash(salt + password))

There were, as always, more constraints on the implementation than can easily fit in a forums post. For example, the password database was legacy, containing many many millions of existing users, and not subject to change. The goal was to secure sign-on, not the legacy password database.

It's still not an example of what the OP or any other reader of this thread should do. Descriptions of cryptographic protocols that leave out essential facts are worse than no description at all. And they should be attacked based on the worst possible resolution to a particular piece of ambiguity. For example, some of the things in the next paragraph might be obviated by identifying what the other parameter to HMAC would be.

The scheme described is still not good at protecting passwords even under the given constraints -- even under the assumption that the attacker can't steal the values of hash(salt(username) + password) directly from the database. Since the salt is derived from the username, the attacker just has to listen to the challenge, and then the response. Then he can efficiently iterate through passwords until a matching response is found. So that protocol shouldn't be run on an unencrypted connection. Also, it wasn't mentioned that the server's challenge is authenticated. Thus, the attacker could also supply a fake empty challenge to the user, and get back HMAC(hash(salt + password)), which is more efficient to attack.

Quote:Of course there are statistical attacks on straight-forward hashes (optionally with fixed "secret" keys). Just sort by frequency, and compare to a table of known passwords sorted by frequency. The match-up will be almost 1:1 for sufficiently large password databases.

For sufficiently large password databases. For human population sized databases and smaller, the match-up will be nowhere near 1:1, and if there's an area where you won't get swamped by noise, it will be only the most extreme common passwords, and you could get those by sending login attempts to the server anyway. (That's assuming an ideal password frequency table. To be more realistic, we don't have anything approaching population-sized tables of known passwords sorted by frequency. So no matter how large your password database is, you won't get a 1:1 match-up, and you'll be the one with the more accurate distribution.)

More importantly, you're still going to need to check these passwords by logging into the server. Your practical login-checking algorithm you use doesn't care if you've estimated password<->hash probability pairs using statistical reasoning -- it'll run the dictionary against the users in the same order (starting by targeting the users with the most common hashes) anyway.

To clarify the Blowfish issue, the idea in bcrypt is not to have a good encryption, but to use an encryption that has a really annoying key setup time. The authors even modified Blowfish to have a yet slower key setup.
The password is used as encryption key, so the longer the key setup, the harder it is for an attacker to try a million different keys per second. The logic is a bit flawed, in my opinion, but it's along these lines, anyway.

In my opinion, just running 4-5 hash iterations (of SHA-1 or whatever) and throwing in some (like 32 or so) bits of salt every time is much easier and just as good. It's not much different from what bcrypt or BSD's MD5 hash do, anyway, only much slower.
You could for example use a user's ID and account creation timestamp (both of which are in your database for "free"), and hash that for salt. Not precisely true random, but pretty close for what it's used (tieing a hash to a user account).

So, the latest CUDA machines could (in theory, neglecting memory bandwidth and synchronisation) test a billion keys per second, and someone could own a farm of 50 machines with 4 cards in each one. Woah, what an utility bill. But seriously, so what? Someone can brute force 200 billion keys per second. It doesn't matter, it won't get him anywhere.
It is no secret that every commodity PC can brute force a 6-8 letter password in under a second. We're only talking of about 30 bits of key space, too. Add 32 bits of salt, and it already looks quite different. Not enough? Add 128 bits, it costs you next to nothing.

Of course, if it's the NSA who is trying to steal your passwords, they might have a million times as much computional power. Throwing in 5 hash iterations with 32 bits of salt each time means the brute force takes about 2160operations. Assuming the cryptographic hash function you use is only marginally worth her name, that means see you in 1023 years.

Seriously, it is much more likely that a user will be stupid enough to tell a phisher his password freely. I dread to think how many people would actually reply if you sent out a mail such as "Hello this is the Citehbank, I need to know username and password and 3 TANs for check all money still there".

Quote:Original post by hplus0603

Quote:"Hello this is the Citehbank, I need to know username and password and 3 TANs for check all money still there".

Speaking of which: Any good, peer-reviewed, secure solutions to that problem? That, I would be seriously interested in (and impressed by)!

Easy, don't give them a password :) A password protected/encrypted private key/certificate should work quite well. Bonus points for using it to establish the SSL/TLS session.

I think it's been proven by the amount of scams/phishing attempts we see, that passwords are just not very good mechanisms for security by themselves. Users have been conditioned to type in the password when ever asked, without too much thought given to whom they are giving it to. Better to give them something they can't give away easily, like a certificate.

Initial distribution of the certificate could be an issue. Perhaps we need a hardware token to make it secure? I wonder if an actual fingerprint would work...?

Hmmm...fingerprints would be quite good. You can't really give them to anyone, it's quite noticeable if they are stolen and the user can never forget them. The readers are a little more common nowadays but you'd still have to make that method optional. Food for thought anyway.

Regards
elFarto

Quote:Original post by elFarto

Users have been conditioned to type in the password when ever asked, without too much thought given to whom they are giving it to. Better to give them something they can't give away easily, like a certificate.

A former bank of mine, many years ago, would do this. No password, install software, it installs and validates the certificate and voila - from then on, whenever you log in, certificate ensures authenticity. A few weeks back I had to set up the system for same bank again - despite their software still being documented using win98 screens, uses same authentication system.

In other words - anyone that opens a browser on that computer has access to entire bank account - no password, nothing.

Quote:Hmmm...fingerprints would be quite good. You can't really give them to anyone, it's quite noticeable if they are stolen and the user can never forget them. The readers are a little more common nowadays but you'd still have to make that method optional.

An acquaintance of mine had their office broken into. They stole PC + card reader + authentication card. Fortunately, the password wasn't written down anywhere, so by the next morning, the perps could not have either contacted support or find it out otherwise. The measly 12345 password (or whatever it was) saved the account.

Quote:Original post by Antheus

Quote:Original post by elFarto
Users have been conditioned to type in the password when ever asked, without too much thought given to whom they are giving it to. Better to give them something they can't give away easily, like a certificate.

A former bank of mine, many years ago, would do this. No password, install software, it installs and validates the certificate and voila - from then on, whenever you log in, certificate ensures authenticity. A few weeks back I had to set up the system for same bank again - despite their software still being documented using win98 screens, uses same authentication system.

In other words - anyone that opens a browser on that computer has access to entire bank account - no password, nothing.

As mentioned above, you need to password protect the certificate to stop people just stealing that.

Quote:Original post by Antheus

Quote:Original post by elFarto
Hmmm...fingerprints would be quite good. You can't really give them to anyone, it's quite noticeable if they are stolen and the user can never forget them. The readers are a little more common nowadays but you'd still have to make that method optional.

An acquaintance of mine had their office broken into. They stole PC + card reader + authentication card. Fortunately, the password wasn't written down anywhere, so by the next morning, the perps could not have either contacted support or find it out otherwise. The measly 12345 password (or whatever it was) saved the account.

I'm not entirely sure on your point here, other than to say 2-factor authentication is better than 1..? Hardware tokens must have their PIN/password set otherwise it makes them just as bad as passwords.

Regards
elFarto

Quote:Original post by samoth
In my opinion, just running 4-5 hash iterations (of SHA-1 or whatever) and throwing in some (like 32 or so) bits of salt every time is much easier and just as good. It's not much different from what bcrypt or BSD's MD5 hash do, anyway, only much slower.

5 iterations of SHA-1 is no good. It's only slightly more expensive than one iteration! PBKDF2 will recommend 1000 iterations as a minimum, but really you want a lot more than that. (Edit: Regarding "but really you want a lot more than that": Do you really? I think I just made that up.)

Quote:
It is no secret that every commodity PC can brute force a 6-8 letter password in under a second. We're only talking of about 30 bits of key space, too. Add 32 bits of salt, and it already looks quite different. Not enough? Add 128 bits, it costs you next to nothing.

The attacker doesn't have to brute force through the salt. The attacker already knows the salt. If you had a safe place to store your salts, you'd put your passwords there.

[Edited by - sam_hughes on August 20, 2010 7:51:22 AM]