I want my time back, three pages on basically nothing.
I broke into my house last year because I lost my keys -> brb writing an article titled "How I became a burglar and locksmith"*
*I took my keys from in the house so... by ars standard that's serious theft.
Rather than reading that article might I suggest having a gander at moxie's https://www.cloudcracker.com and read his blog too for all the goodies.
>>I want my time back, three pages on basically nothing.
Yeah, it's shameful that such a poorly written article is being touted as a "feature story." Then again that's what happens when your editor-in-chief demands articles of a certain length and you don't have much to say, so you fill three pages with bullshit. Kind of like in college!
Regarding your tips on passwords, one technique I used to employ in password security was the following:
When the user signs up, store a Timestamp for creation date, then take their email address and use it as a prefix and suffix to salt the password, for instance:
If the users password is shanelja, then the routine would be as such:
TIMESTAMPshaneljaEMAIL
or in my case:
147182994718shaneljashanea93@hotmail.co.uk
This produces a ridiculously hard password to brute force.
While this may be easy to compute if you know the rule, the general rule of thumb is that if your server has been attacked in such a way that the attacker has a copy of your database, they will most likely know the rule in any case, so it makes sense to have a good one.
Outside of this, no one should be using MD5 in this day and age, I would even recommend against Sha256 and other variants in that family, though I have a lot of respect for Blowfish, etc.
Sorry, I didn't think my last comment needed clarifying any further - I actively use the bcrypt class for password hashing - I said Blowfish originally as I was comparing hashing algorithms.
Most encryption algorithms (including block ciphers) can be used as a hashing algorithm for passwords.
Just encrypt a common known plaintext string and use the password as the encryption key. This is exactly how various hashing schemes like UNIX's crypt() (based on DES) work.
Knowing the plaintext (e.g. a set of NUL bytes) is useless as long as the encryption scheme doesn't have a weakness against known-plaintext attacks [EDIT] that allow you to recover the encryption key somehow.
Yes, and Blowfish (or rather, a variant of it with an expensive key schedule) is used as the main building block of Bcrypt in roughly the way you describe. That doesn't mean that Blowfish is Bcrypt.
I feel like such a pedantic dick for harping on this, but the distinction is worth making.
The "don't use bcrypt" is really just think about it before you choose it. He says in the first sentence "If you're already using bcrypt, relax, you're fine, probably."
The other algorithms he mentioned were "scrypt" (mentioned already by GP) and "pbkdf2"[1]. The algorithms really just lie on a line between "well studied" and "theoretical security" with bcrypt in the middle. With the author dismissing bcrypt because its worse than each of the others in one attribute ignoring that it's better than the other in that attribute. Also ignoring that bcrypt libraries are generally more popular and hence more reviewed.
The real point was not inventing your own salting / hashing algorithm.
This is a million degrees of wrong. With bcrypt, scrypt, and PBKDF2, there is no "adding a salt". It's an inherent part of each algorithm. If you're "building" a salt, you're doing it wrong, period.
> It's trivial to build a lookup table like with md5, it just takes longer.
No, that's not true, because each one is initialized with a completely different public salt. You can't generate lookup tables for it, without covering the entire hash space.
Of course there is. As you said, it's an inherent part of the algorithm. But never put it beyond some people to use a trivial salt (or use the same one for all users)
"because each one is initialized with a completely different public salt"
If they follow the proper procedures, yes, building a lookup table is impossible.
Checking the python libraries they make it really easy to use, but you can provide your own salt if you want (you have to manually call 'gensalt' as well)
>Outside of this, no one should be using MD5 in this day and age, I would even recommend against Sha256 and other variants in that family, though I have a lot of respect for Blowfish, etc.
@shanelija SHA-256 is a secure cryptographically secure hash function. It is not and was never intended nor should be used as a key derivation function.
Given time and email are not unique, they should not be used as a salt. Concatenation of a salt is not the correct method either, not for KDF and not for message authentication.
One of the aims of a hash functions is to be fast, really fast, super fast while making it computational infeasible to:
make a message that will hash to a given value
alter a message that when hashed will produce the same or a give value.
Find two different messages with the same hash value.
bcrypt, scrypt, PBKDF2 are perfect for password storage.
YOU are not off the hook yet until you repeat these 2 sentences 10 times:
A secure crypto algorithm/system/function/whatever MUST continue to be secure even if the algorithm/system/function/whatever is public.
It is perfectly fine to homebrew crypto given one key condition, you never ever ever ever use it for things that matter.
Because part of the puzzle is in the source code, and if the attacker got the encrypted user table from the common method of SQL injection they don't know the rule which is defined only in the function which checks validation of the pw and generates the pw hash.
What I do similar is,
Pw_hash = hash('f4/$$er3@' + salt + plain_text_pw);
If the attacker only gets the database (which has the hash and the salt) and not the source code they don't have the 'f4/$$er3@' value needed to perform any attacks
There is zero requirement that salts be kept secret in the event of a password database breach. Salts are to prevent users with identical passwords from having identical password hashes, thereby defeating rainbow table attacks (and other attacks involving attackers being able to reuse work from other accounts).
Your approach offers effectively zero additional security; it is trying to add "features" to salting that don't work towards their actual purpose.
Edit: If you want to have something site-wide that an attacker wouldn't have while decrypting an offline password database, the thing you're looking for is an encryption key.
To be honest, there isn't any, when I implemented it I was the tender age of 16 and thought there was some validity in the method, but in itself, once you get to these kind of 30-ish letter long passwords, they become damn near impossible to brute force.
The only redeeming factor I suppose would be that you have to store your random string somewhere anyway, at least this method required code traversal rather than just an SQL field named "password_salt".
Mostly because it's very quick to compute millions of hashes, meaning that it lessens the time required to crack a bunch of passwords - of course, this might seem like the last of your problems if your system has been attacked, but most of your users probably have the same password for every site they use, including Paypal, etc.
Something which can be scaled to take a lot longer to hash can make it expensive and practically unfeasible for someone to crack more than the simplest passwords.
