I've got an old application that has user passwords stored in the database with an MD5 hash. I'd like to replace this with something in the SHA-2 family.
I've thought of two possible ways to accomplish this, but both seem rather clunky.
1) Add a boolean "flag" field. The first time the user authenticates after this, replace the MD5 password hash with the SHA password hash, and set the flag. I can then check the flag to see whether the password hash has been converted.
2) Add a second password field to store the SHA hash. The first time the user authenticates after this, hash the password with SHA and store it in the new field (probably delete their MD5 hash at the same time). Then I can check whether the SHA field has a value; this essentially becomes my flag.
In either case, the MD5 authentication would have to remain in place for some time for any users who log in infrequently. And any users who are no longer active will never be switched to SHA.
Is there a better way to do this?
Essentially the same, but maybe more elegant than adding extra fields: In the default authentication framwork in Django, the password hashes are stored as strings constructed like this:
hashtype$salt$hash
Hashtype is either sha1 or md5, salt is a random string used to salt the raw password and at last comes the hash itself. Example value:
sha1$a1976$a36cc8cbf81742a8fb52e221aaeab48ed7f58ab4
You can convert all your MD5 Strings to SHA1 by rehashing them in your DB if you create your future passwords by first MD5ing them. Checking the passwords requires MD5ing them first also, but i dont think thats a big hit.
php-code (login):
prev:
$login = (md5($password) == $storedMd5PasswordHash);
after:
$login = (sha1(md5($password)) == $storedSha1PasswordHash);
Works also with salting, got the initial idea from here.
I think you've already got the best possibilities. I like #1 more than #2, since there's no use for the md5 once the sha is set.
There's no way to reverse the MD5, so you have to wait for the user to authenticate again to create a new hash.
No - basically you'll have to keep the MD5 in place until all the users you care about have been converted. That's just the nature of hashing - you don't have enough information to perform the conversion again.
Another option in-keeping with the others would be to make the password field effectively self-describing, e.g.
MD5:(md5 hash)
SHA:(sha hash)
You could then easily detect which algorithm to use for comparison, and avoid having two fields. Again, you'd overwrite the MD5 with SHA as you went along.
You'd want to do an initial update to make all current passwords declare themselves as MD5.
Your second suggestion sounds the best to me. That way frequent users will have a more secure experience in the future.
The first effectively "quirks-mode"'s your codebase and only makes sure that new users have the better SHA experience.
If the MD5's aren't salted you can always use a decryption site/rainbow tables such as: http://passcracking.com/index.php to get the passwords. Probably easier to just use the re-encode method though.
Yes you should know the real password first before you convert it into sha-1..
If you want to find the real password from md5 encrypted string, you can try md5pass.com
Related
By using salt, I understand that password would be added with an random generated salt before storing into database.
However, I dont quite sure whether the salt is unique for each passwords or all password is only mixed the same "random generated" salt
For example，
Under my application, there are two users and there two passwords: user1password1 and user2password2
Their passwords would be mixed with salt for sure. But, before storing into db, the results are
user1password1 + salt , user2password2 + salt
or
user1password1 + salt1 , user2password2 + salt2
Ideally your salt should be unique per user or per password.
Now, as you said before storing the password in a DB, you should hash them with a password-based KDF such as Argon2. (Not with a hash function.)
Using a single salt
There is one main problem if you use the same salt for all of your password: it lowers the cost of an attack against your database because an adversary, Eve, can take a dictionary of "common password" let us call it "rockyou.txt", and it is enough for her to try and hash all of the passwords contained in rockyou.txt once using that salt to try and break some of your users' password.
Basically this means the work-factor to find the pre-images of multiple hashes in your database is low.
Using different, randomized salts
Whereas using a different salt for each user (or each entry in the password database even) means that Eve has to re-do the computations where she tries to hash all the words in the rockyou.txt dictionary to try and find the pre-image of a single hash in your database.
So here, the work-factor is large, since it has to be re-computed for each single password hash.
So if you can store one large (128 bits ideally or more, but 64 bits would be okay-ish is storage is a concern) random salt per password, please do it and make sure you are never storing plaintext password, but only their hashes.
Is it safe to hash extremely complicated password (longer than 25 chars, any ascii chars even binary) with SHA1 ?
Actually, the password represent a tokenID but I don't want to store it like this in the database, i prefer to hash it for more security.
The password (token) is valid only for 14 Days and I need to hash it the most faster as possible (so no way to use something like bcrypt)
What must be the ideal length of the Password (token) ?
In the general case, no. "Complicated" it may be, but cryptographically random it probably is not.
A bare minimum would be applying an RFC2104 HMAC with a secret key (pepper); however, a more appropriate alternative that can, if you absolutely insist, still be quite fast would be to use PBKDF2-HMAC-SHA-256 and ignore all rules of security regarding a sufficiently high iteration count, i.e. choose an iteration count of 10, instead of 10,000.
For password/token hashing, of course, never request more bytes of PBKDF2 output than the native hash function provides - 20 for SHA-1, 32 for SHA-256, 64 for SHA-512.
I have several example implementations of PBKDF2 at my Github repository that may help, and there are others in other languages, of course.
Use a cryptographically random per-password (per-token) salt.
Long story short I want to be able to read passwords stored in our database to be able to query weak passwords for our employees as there are currently no restrictions. What I've been doing in the past is changing it from the front end to see what it looks like on the backend. For instance this is what "password" looks like on the back end JXm7CJyoCBnURIrneTtflA== .
I'm not sure if this is possible, or what type of encryption is used. Any help would be great!!
Thanks
This particular field is Base64 encoded, and has 16 bytes if you decode it (Convert.FromBase64String). This smells like a MD5 (hash algorithm) - especially if other fields have also 16 bytes when decoded. There is no way in hell how to decrypt hash (there are some options like rainbow tables but you can't be 100% sure). Algorithm works like this: you hash password in db, you hash whatever user puts in as password when he logs in and hash it as well - if hash matches user has entered correct password.
I asked a question yesterday about secure hashing, which got me thinking about how one would actually go about breaking a password created with a custom hashing algorithm. My current (very unsecure) password script uses an iteration of sha1 on the password, and then an iteration on the hash generated by that prepended with a 3 digit salt.
$hash = sha1($pass1);
//creates a 3 character sequence
function createSalt()
{
$string = md5(uniqid(rand(), true));
return substr($string, 0, 3);
}
$salt = createSalt();
$hash = sha1($salt . $hash);
Now I, being the administrator of this server and having complete access to the source code and password table, plus administrative tools can simply reset a user's password to whatever I would like, but for the sake of understanding security better, I am curious how to go about doing this the way a hacker would. I have a program called cain & abel which brute forces against a specific hash algorithm, but how would I do something like taking each attemped password, sha1 ing it, concatenate it to the (known) salt, and sha1 ing it again? This seems like it would be very simple to do, but I have never programmed in a language like C++ and I presume that is what is necessary.
EDIT:
I should specify the following:
This is an offline brute-force attack.
I have the database full of hashes and their respective salts.
The salts are per user, but I only want to attack one user's password at a time.
Specifically, I am asking how to brute force a password using a custom series of hashing algorithms, such as the one I showed above:
pseudocode:
$hash = sha1( 'password' );
$salt = '3Sf';
$hash = sha1( $salt.$hash);
I presume whatever method would be used to do this could also be used to brute force a password hashed with a known algorithm such as:
$hash = sha1( 'password' );
$salt = '3Sf';
for($i; $i<1000; $i++){
$hash = sha1( $salt.$hash);
}
So I am not specifically asking for the CODE to do the first thing, I am asking by what method I can run a brute force program against a customized hashing algorithm like the 2 I have listed above.
NOTE: I am in no way stating I am likely to encounter this situation, but I would like to know how it is done.
To my knowledge, no broadly available hash-cracking tool supports this functionality.
However, as you said, it would be extremely simple to write a program to crack the hashes given enough time.
If your attacker already knows your way of computing the salted hashes, we can safely assume he either has access to your DB (which would necessarily store the salts as well), a dump of it or access to plaintext communication between your app and a client.
To then crack the hashes, he would simply replicate your sha1($salt . $hash) function and start feeding common passwords to it. This would save time compared to purely brute forcing all possible combinations. He'd take the $salt from you DB and compare the result of the hashed-salted-hashed password to the salted hash stored in the same DB.
If the resulting hashes match, the password has been "cracked".
In general, using individual salts for each user is a good idea as it increases the time to crack an entire DB table of passwords exponentially. Instead of running a wordlist against a single hashing function with a single salt, he'll have to run the entire wordlist against every single hashed PW in your database.
That said, if the attacker is far enough into your system to actually acquire the hashes / salts it would be much easier for him to alter your code to send him plain text copies of credentials of users logging in in the first place.
Much too simplistic of a question. There are a lot of things to consider and way too many to hit on in one post but here are a few. 1) Does the hacker have the password store? If so, brute force attacks can be more successful because there are no other mitigators to keep the attack from proceeding. 2) Has the hacker been able to penetrate your system and reveal your salt/hashing systems? This will make it much easier for the brute force attack especially if 1 is true. 3) If 1 and 2 are false, are there mitigation systems in place to prevent/slow a brute force assault such as locking an account after a number of incorrect passwords in a row etc.
By and large, phishing and especially spear phishing are much more likely to succeed on a well maintained/secured system than brute force, though brute force is a great way to achieve DOS as well. There is a whole discipline based on this topic and soooooo much more to consider.
Is it possible to decrypt a SHA1 string in VB.Net, knowing the key?
I have seen "decryption" of credentials before, however - in Java: http://pastebin.com/P0LuN00P
The entire point of SHA1 is to make this impossible.
However, SHA1 has weaknesses which make this less impossible.
You should use SHA512 to make it more impossible.
You might be looking for Rijndael, a (good) symmetric encryption algorithm.
I think you got SHA1 wrong.
SHA1 is not an encryption algorithm, it is a hash function.
A hash function is a function taking some unconditionally long argument string and transform that string to a much smaller string, called the hash. It is very hard to get from a hash to the string used to generate the hash. Actually, since the input are arbitrarily long, there are multiple such inputs that give the same hash. Two such inputs are called collisions. Therefore you really cant "decrypt" a hash, you can find a input which gives the same hash though.
Commonly hashing functions are used to hash a user password, store it in a database on the server. When the server is supplied a password from a user, the server checks to see if the password is correct by checking that hashing the password gives the same result as stored in the database.
If a malicious user grabs what is stored in the database, he is unable to know the actual password since it is very hard to go from hash to the string used to generate the hash.
SHA1 isn't encrypted, it's hashed. So no, it's not possible to decrypt it. You might try a Rainbow Tables: http://www.freerainbowtables.com/