6 ms·
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
by shanelja 14y ago
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.
- sparky 14y agoJust use bcrypt [1] (or scrypt [2]) [1] http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/ [2] http://www.tarsnap.com/scrypt.html http://www.tarsnap.com/scrypt.html
- shanelja 14y agoBcrypt uses the blowfish encryption algorithm published by Bruce Schneier in 1993. [1] I do. [1] http://bcrypt.sourceforge.net/ http://bcrypt.sourceforge.net/
- pjscott 14y agoBcrypt uses Blowfish, but it is not Blowfish.
- shanelja 14y agoSorry, 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.
- pjscott 14y agoBlowfish is a block cipher, not a hashing algorithm.
- shared4you 14y agoI'm no expert, but [1] says: > bcrypt is an adaptive password hashing algorithm [1]: http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/
- pjscott 14y agoBcrypt is an adaptive password hashing algorithm. Blowfish is a block cipher.
- alexkus 14y agoMost 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.
- chickopozo 14y agoEncryption does not provide Integrity (hash) or authentication (mac) crypt(1) should be an example of how not to do hashing.
- alexkus 14y agoPerfectly true, but those points are irrelevant for password hashing.
- pjscott 14y agoYes, 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.
- stouset 14y agoIf you use bcrypt, there is literally no reason to go through the manual "salting" process you describe.
- shared4you 14y agoSomeone else explicitly says "Don't use bcrypt" [1] [1] http://www.unlimitednovelty.com/2012/03/dont-use-bcrypt.html http://www.unlimitednovelty.com/2012/03/dont-use-bcrypt.html
- asdfaoeu 14y agoThe "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. [1] http://en.wikipedia.org/wiki/PBKDF2 http://en.wikipedia.org/wiki/PBKDF2
- raverbashing 14y agoUsing bcrypt or scrypt or PBKDF2 is useless if you hash only the password with it. It's trivial to build a lookup table like with md5, it just takes longer. Salting is essential. I don't know why the parent was downvoted (probably because his salt is predictable?) so good salting is needed. Example: WPA2 uses the SSID as the salt and PBKDF2 to derive the encryption key.
- daeken 14y agoThis 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.
- raverbashing 14y ago- there is no "adding a salt" 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.
- d4n3 14y agoThe actual output from the bcrypt library is: [salt]$[hash] You don't set the salt yourself, the library generates it from from a secure RNG. For someone that's not that into security, it's easy to use and hard to get wrong.
- raverbashing 14y agoThanks for clarifying 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) So pretty safe if you copy their examples.
- pluies_public 14y agoUh? What's the advantage of this technique over a randomly generated salt?
- shanelja 14y agoTo 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".
- deleted 14y ago[deleted]
- torya 14y agooh snap!
- zobzu 14y agowell, its a salt, too. just not so random. ;-)
- jasey 14y agoBecause 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
- stouset 14y agoThere 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.
- jlgaddis 14y ago> I would even recommend against Sha256 and other variants [...] Why?
- shanelja 14y agoMostly 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.
- chickopozo 14y agoBut if you read up I have explained, fast is better in hash functions.
- chickopozo 14y ago>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.
- dhimes 14y agoshanelija said s/he uses bcrypt. Apparently s/he just makes the passwords stronger than the user makes them before hashing.