You're exactly the guy I'm talking about. "Oh, I use AES, but I don't just use AES; I store the secret IV for AES in a cookie so even my server can't decrypt it unless the client comes back with the IV so it's like two guys in the silo with the missile keys". Seriously, I just found that piece of code yesterday. Did you write it? Stop writing that stuff.
I can probably top you: some many years ago, I discovered that Network Solutions (the original domain name provider) was using the first two characters of the password as the salt for their user accounts, presumably so that the salt could also be secret. Of course, this had the side-effect of making the first two characters of the password visible in plain text if you looked at the hashes. I reported this as a bug and never heard back. I've also never done business with Network Solutions since then.
So the salt was just added to the hash without hashing the concatenated hash + salt, i.e was this the method they chose?:
saltedhash(password)=hash(password).salt
A part from the obvious flaw of including part of the password in plain text, how secure is this method compared to the following method were the salt is not a secret and were the concatenated hash + salt is hashed?:
saltedhash(password)=hash(hash(password).salt)
Perhaps in retrospect, but this was standard for the Unix crypt() function and passwd files of the time: http://linux.die.net/man/3/crypt
The dangers of rainbow table attacks weren't well considered at the time.
The real error was misreading the man page and using the first two characters as the salt, which is then published as the first two characters of the hash. It's sort of an easy error to make, because to decrypt, you do use the first two characters of the hash. Understandable for a beginner working on a school project, but pretty ludicrous for a large company holding control over most of the domains on the internet at the time.
No; I use standard, time-proven, secure designs. SHA1(salt + password) is sufficient in almost all cases, and if anybody is capable of deriving the original input from the digest, they can do so no matter what digest algo is used.
I know there's lots of ways to screw up security, but most of them derive from lazy people taking shortcuts. They run the httpd, database, and authentication all off the same server so a vulnerability in one compromises all. They store secrets in the database because figuring out secure storage would take half an hour of research.
Replacing a poorly-implemented SHA1-based system with a poorly-implemented bcrypt-based one won't help security.
SHA1(salt || password) is an incompetent design that is debatably even easier to crack than the Gawker hashes. The insecurity of that construction is why we have PBKDF2.
If the entire knowledge you have of cryptography comes from _Applied Cryptography_ --- wait; let me extend that: if you even feel the need to cite _Applied Cryptography_ --- you should be careful debating crypto constructions. You're not going to end up happy.
I'm curious what the attack is that makes that easier to crack than the Gawker way. (I'm sure you're right, I just didn't know that it would be easier.)
SHA1 might (I think it is, but I'm not sure) be faster than DES; among other differences, DES crypt(3) has to run the DES key schedule before producing a hash. Data slips through SHA1 like a greased seal.
Ah, alright. I was thinking there was some kind of length-extension weakness (which doesn't apply here, which is why I was confused) or some other attack in the cryptographic sense. Thanks.
SHA1(salt || password) does have a length-extension property; you can easily compute SHA1(salt || password || junk || arbitrary-data) for any given hash. That's not very useful for password hashes, but is devastating for the kinds of SHA1-based authentication schemes that people who write their own password hashes seem to come up with.
It's not deep enough to provide true knowledge of cryptography and cryptographic attacks while it also doesn't give practical advice on what to actually do in situations that require cryptography (read: always use high-level primitives). Applied Cryptography is pretty good (if outdated), I think, if you're seeking to gain a beginner-level knowledge of cryptography. Practical Cryptography, on the other hand, is a far better choice for what to do when actually using cryptography (although even that is outdated now).
Haha I'll take you up on that when I get back to Northwestern. I'll admit that the only reason I think it's outdated is because I was just teaching basic cryptography to the network security students and ran across a few things that made me think "Hmm, Niels/Schneier should really include this in their next printing." Some things I'm thinking of are EAX/GCM instead of the conventional CTR.
Quoting me: "Lots of random facts about crypto trivia. Not a lot of context. Even less information about how to actually safely use crypto primitives. You'll come out of it knowing how to get CAST or IDEA into your code --- two ciphers nobody uses anymore --- but not how to properly choose an IV for CBC mode."
> No; I use standard, time-proven, secure designs. SHA1(salt + password) is sufficient in almost all cases, and if anybody is capable of deriving the original input from the digest, they can do so no matter what digest algo is used.
Anyone can create an input that hashes to a given value. The relevant factor is how long it takes to create that input. I hope you can see the difference between that process taking 3 seconds vs 40 years.
You're exactly the guy I'm talking about. "Oh, I use AES, but I don't just use AES; I store the secret IV for AES in a cookie so even my server can't decrypt it unless the client comes back with the IV so it's like two guys in the silo with the missile keys". Seriously, I just found that piece of code yesterday. Did you write it? Stop writing that stuff.