In my program I get the password into a variable (eg:string) and then before storing it into the database I hash it.Is that the correct and secured method?
Or should I hash it before storing it into a variable i.e. as soon as the user type in the password should it be hashed?
#Erina
Think about the purpose of hashing.
If someone breaks into your database they will not find passwords but only hashes which need to be brute forced into passwords in order to be useful.
By allowing the client to send a hash instead of the password you effectively make the hash the new password and all benefits are lost. i.e. if someone gets into the database they can instantly log into all accounts with the data they find there.
Therefore the client should always send the password and the server should do
the hashing.
Related
For example let's say my password is "foo" and the website is using a md5 hash on passwords with a unique salt appended to it.
So when I register my password will be stored as "foo" with a salt appended to it and then md5 hashed.
Then when I send a login request the website will append a salt to "foo" and then md5 hash it, but how will the website know what the correct unique salt to use is?
How will the website magically know the correct unique salt to append to my password which is then md5 hashed, to verify the password I entered is equal to the md5 hashed salted password in the database?
This is the usual process of handling passwords:
User registers with a password.
A new data record is created for their user ID (which can come in the form of username or email, etc.)
Their password is handled:
A salt is generated for them, and that salt is saved in the data record. It's very common and recommended that the salt is visible right next to the password hash.
The password is combined with the salt (typically a library handles even this step for you, as any little nuance like appending salt matters a lot in security).
The password is hashed using a function designed for password hashing. This is usually quite computationally expensive to frustrate brute force attempts.
The password hash is stored in the data record, and the original password is discarded.
Then when they log in, there's no magic here:
The data record is looked up using their user ID.
The password they give is combined with the salt from the data record and then hashed.
If it matches the hash stored, they are granted access.
Some notes:
Password hashing is expensive. I don't think it's uncommon for it to take more than 1 whole second of computing time. Imagine the processing load if a thousand people are logging in at once.
A lot of things can go wrong if you aren't using a decent library to handle password hashing. Writing any of the steps yourself is not recommended.
It's common for libraries to output a coded string that contains everything you need to verify against a password, such as a version code, the hash, and the salt used.
I'm studying a migration from an old LDAP to a new database.
Today I just found that the passwords are all saved as {crypt} passwords and the new system does not support that.
Is it possible to decode the {crypt} passwords (in PERL if possible) ?
No, crypt implements a one way hash.
However, you have the hash values and (hopefully) the salt. Whenever a user submits a password, it's encrypted with the same salt, and if the hashes match, the user is authenticated.
In general, it's a very bad practice to have human readable passwords, but you don't need to read a raw input password to authenticate a user.
The answer should be no. The whole point of hashes such as crypt is that you can't do that. However, if it's using the old-fashion unix crypt(), it's often actually quite brute-forceable (it's rather weak cryptography). Question is, should you really want that.
This is sounding like an XY problem though. What LDAP servers are we talking about, and what formats do they support? There's a reasonable chance there's some kind of overlap that can be used for migrational purposes.
If implemented correctly a password stored as crypt can not be decoded into cleartext because it is not encrypted but hashed.
Depending on your target system you might be able to migrate the hashed passwords "as-is", but you have to determine which hash was used and if the same is supported by your target system.
You need to disclose more about the LDAP server and the database you use.
I have a database with roughly 4,000 members. I need to decrypt all their passwords so that I may re-encrypt them using MD5 and put into a new system. I have one account with before encryption and after encryption password strings so with this I assume I should be able to figure out a method and key range. I do not have access to the original source code or I would not be here.
I should mention that existing passwords vary dramatically.
User1 - qwDyP1db9iOPI
User2 - $1$.WXtDyLg$yxBPAWxzd.srEWJZfqZAY/
User3 - do8sLMoVVqxKQ
User4 - TKmnAlPe
How do I approach such a problem?
Typically, you can't decrypt the passwords, because the passwords are not stored. What you are seeing is hashes of the password - there's no efficient way to find a password that matches a particular hash.
You can either force everyone to change their password once you have the configuration changed to use MD5 hashing, or you can generate new temporary passwords for everyone to get all the hashes replaced at once, but then they should all change them again anyway.
Those look like they probably came from Linux (the one that starts with $1$ is already an MD5 hash, the others look like the older crypt() DES variant style).
That's not always the case when dealing with application passwords - for example, some databases use considerably weaker credential storage - but Unix/Linux flavors have not stored actual passwords for a very long time, if ever.
let's think. Suppose I can hack my way to your computer / DB (not an impossible task). So I have what you have - a list of all users' passwords, but encrypted. But most probably I can register to your system myself, and I know my own password. I can find its encrypted form in the DB, either by my username, or by the latest entry, so now I have the clear + encrypted pair! If I could do what you are asking, I'd have all passwords and full access to all accounts. Meaning that encrypting passwords, or data in general has virtually no additional security effect, and all I should care about is preventing unauthorized access to the data. But this is not true, so you can't :)
BTW, MD5 is not an encryption but a hash, or more correctly a digest.
Looks like twalberg is right for the most part, but I'd like to go a step further to give you some practical advice:
1) Look at http://www.openwall.com/john/ (John the Ripper) for help getting the original passwords out of the database you have. Note that the passwords generated may not be the original passwords (it is likely, but not certain).
Once you've gotten all of the passwords using this tool, think to yourself: Anyone could do this. Your users might use these passwords somewhere else. If someone broke into your site, they could expose the people who trust you. Your users could blame you if someone used this information to break into their other accounts. Having the cleartext passwords around is risky for you.
I recommend you take this opportunity to have your users change their passwords. Those that no longer use their accounts should probably have to go through a small verification step to regain access, so you can disable their accounts now.
2) When you generate the new password database, I recommend you at a minimum use a secure hash (E.g. SHA1 or SHA2) along with a per-user salt (random value prepended to the generated hash output in a standard way) to help secure the database from accidental exposure.
While this answer isn't efficient, it is probably practical for the most part for your current database if your actual password database has even approximately the proportions you represent.
If you're switching away from your current system don't switch to plain MD5 - there are "rainbow tables" to crack a lot of common passwords; instead use salted/double MD5 or SHA
Thanks all for your input. I will just have everyone change their passwords. I have no intention of keeping anyone's password. The goal was to not have all 4000 users have to change their passwords after migrating to the new system but it seems unavoidable. As davka pointed out, I have an account in this database and know my password and can see the encrypted version so thought that would be sufficient to develop a script that decrypts and renters the password into the new database. Thanks again.
I came across a table the other day on our enterprise system -- dba_users (oracle).
I was able to find a hashed password in this table for each employee, and also their username.
As far as I know (from googling) the username + password is concatenated, then hashed.
Question: knowing the "salt" (my own username), the "original value" (my own password), and also the hashed value...is there a danger here of being able to figure-out the hash?
Also -- googling oracle 10g hash -- seems like some folks think they've figured the hash algorythm out. And I've read about "rainbow tables" and "offline dictionary attacks"... And finally, I've googled oracle 11g, and one of the features in that version is they hide the hashed password in dba_users so end-users can't see it.
Anyway, I'm scratching my head over why I (i.e., end-users) have access to this table, and why the DBA dosen't seem too worried about it.
The whole point of hashing the password and then storing the hash to database is that if you do so you won't have to worry about who can see the password in the table.
To emphasize: a (properly calculated) hash value of a password which is stored in database is completely useless without the original.
As far as I know, for algorithms like md5, there isn't a way to reverse engineer the original password from hash whatsoever. That's why most services nowadays don't send you your password when you click 'I forgot' link - instead they offer to set a new one (as soon as you provide the old password and the service compares hashes).
Elaborating on what #Goran Jovic said, by concatenating (ie salting) each hashed password with the username.There is no danger in making this available. To make sense of this, you have to understand how a rainbow table work. The way a series of passwords is cracked with a rainbow table is by loading up a precomputed series of hashes from passwords into memory. Then, searching through the table of hashes associated unknown passwords to see if you can find a match in the rainbow table (of which you know the password corresponding with a specific hash). By salting the hashes with a unique identifier (ie a username), however, you defeat this attack because even a password that's already been seen will hash differently depending n the user associated with it. Therefore now, instead of a rainbow table having to handle the millions of different password combinations possible, it must now contain a hash of every possible password plus every possible username. The results space of this is simply too large to search and unless there was a quantum leap in computing technology impossible to beat using a bruteforce tactic.
Ok, I’m trying to understand the reason to use salt.
When a user registers I generate a unique salt for him/her that I store in DB. Then I hash it and the password with SHA1. And when he/she is logging in I re-hash it with sha1($salt.$password).
But if someone hacks my database he can see the hashed password AND the salt.
Is that harder to crack than just hashing the password with out salt? I don’t understand …
Sorry if I’m stupid …
If you don't use a salt then an attacker can precompute a password<->hash database offline even before they've broken into your server. Adding a salt massively increases the size of that database, making it harder to perform such an attack.
Also, once they've broken in they can guess a commonly used password, hash it, and then check all of the passwords in the database for a match. With a different salt for each user, they can only attack one password at a time.
There's an article at Wikipedia about salts in cryptography.
Another intention behind the use of a salt is to make sure two users with the same password won't end up having the same hash in the users table (assuming their salt are not the same). However, the combination of a salt and a password may lead to the same "string" or hash in the end and the hash will be exactly the same, so make sure to use a combination of salt and password where two different combination won't lead to the same hash.
If an attacker creates a giant table of hash values for plaintext passwords, using a salt prevents him from using the same table to crack more than one password. The attacker would have to generate a separate table for each salt. Note that for this to actually work propertly, your salt should be rather long. Otherwise the attacker's precomputed table is likely to contain the salt+password hash anyway.