Normally a password is stored with a one-way algorithm, so that it makes hard to discover the plain text from it.
But I've been thinking: What if I store a SHA512 of both username and password melted together (A+B=SHA512), instead of the username and the password hash separately.
Is this method secure?
EDIT: In my opinion the Username 'salt' the password, so there will be no equal hash two times...
(1) You should be using something like bcrypt, scrypt, or pbkdf2 instead of something like SHAwhatever for password processing. Google this.
(2) How would you deal with forgotten password scenario?
(3) See my blog, particularly the section on "A simple example: protecting email address": https://littlemaninmyhead.wordpress.com/2015/09/08/a-retrospective-on-ashely-madison-and-the-value-of-threat-modeling/
Sure that would work. But would you ever want to retrieve a list of user names?
In the authentication implementations I have written, I use the username as part of the salt. That combined with a sitewide salt plus a bit of constant salt ends up creating around 120 bits of salt per username.
Related
I have a user table, each user has a password, and a password salt.
I want to reset every user password using a sql script, but I need to know which hash is used for password, here is an example:
pass : $2y$10$WjgvLQbIyx4Oab69b2vEKuOPafgWC2yzWD7JqYvC6dgvjW2iuNi/m
password salt: AF7
It looks as if the hashed password was generated with the PHP function password_hash.
The $2y$10$ at the beginning seems to indicate that the default algorithm was used (second parameter):
password_hash(password, PASSWORD_DEFAULT)
I hope you didn't use "AF7" as a salt for all passwords. That would completely defeat its purpose. It's the same as using no salt at all.
When setting new passwords, it's not relevant what hashing function was originally used. Instead, it's important what's used to verify the password. I assume that PHP's password_verify function is used. So you can easily use a different algorithm and a random salt. It's all encoded in the string that's stored in the database and password_verify will be able to handle it.
That looks like a hash generated by a method such as password_hash, bcrypt or a similar method.
Hashes are not encryption, they one-way functions designed not to be reversible, information is lost, by design, in the hashing function.
Is there a way to do this?
In my mapping class, I want to decrypt a MD5 password when I fetch my database data into entities. Is this possible?
Thank you!
MD5 can be used to encrypt passwords. MD5 is considered as a broken. What you do is you hash the password with MD5 and compare it with the original hash value in the database. Since MD5 is one way, if the passwords are same, hash value is same.
Edit:
If you are looking for cracking MD5 encrypted passwords, That is something different. Take a look at this
You mist first understand that this is not technology specific. These are basic computer science generic concepts which can be used implemented using various technologies. In you case C# and NHibernate etc.
To be simple, what you are doing with MD5(Message-Digest algorithm 5) is, you do hashing. because it is a hashing function. take a look at this.
But this MD5 is a one way hash function. "one way" means that it's nearly impossible to derive the original text from the string. That is why it is used for password encryption. Because you can not reverse a one way function and get the actual password. Take a look at this as well.
I assume that you want to check weather the inserted password is correct and allow log-in or do what ever necessary. You should not be doing decryption a password. If you are not going to crack a password. Password cracking is more of a guessing and scope can be reduced using the weaknesses of implemented methodologies(In MD5 hashing collisions).
In password creation, you take the password and you hash it using MD5(in your case).Then this hash value is what you are going to store in a database. Then next time you want to check weather the password is correct. Then you again take the password and you again hash it using MD5. then you take that hash value and compare it with the hash value in the database. If they match inserted password is correct.
I can see that you are new to SO. What I recommend is that you better learn these concepts first and the these concepts will help you irrespective of what technology you use.
You might as well ask if you can turn a pile of ashes back into the log before it was burned. Hashing is a one way action... you cannot "reverse" it. The only thing you could do is determine some source values that generate the same hash (hash collision).
If I understand correctly, the biggest problem with sending a password via email is that it requires the password to be stored in clear text in the database. If the DB is compromised, the attackers will gain access to all accounts.
Is there a workaround for this problem?
How can one make sending a user their password via email as safe as possible?
The simple answer is: don't. If you think your database is insecure, an email is far, far less.
If you mean that you want to send them their password when they register, then you could do that before you store it in the database.
If you mean after they have registered, the only option is to store in plaintext (again, don't do this) or make a new, random password and send them that. It is impossible to get their password from the hash, which is why it makes the password storage safer. The best option is to generate a new (temporary) password you send them, or a token giving them access to a password change system.
You may want to consider a good hashing algorithm like BCrypt that includes a salt.
I don't know if my suggestion is feasible for your scenario, but you should better keep the data hashed or encrypted and send password reset links instead of plain-text passwords.
The moment the password is in cleartext in the email, it is inherently insecure.
As such, there is no safe way to send a password in cleartext safely.
You should not be storing passwords in cleartext in your database - you should be using salted hashes. When the user enters their password, you hash it with the salt and compare to the stored hash.
When people forget their password, instead of sending passwords by email, you should send reset links backed up by expiring tokens. These would generate a temporary new password (that would expire within minutes).
You should be hashing all passwords in your database.
sha1($_POST['password'].$salt.$username);
In the case of a lost password
A user requests a password reset link, which contains a hash generated in the "user_meta" table. When the user recieves this link, the hash is compared to that in the database, and the user will be able to UPDATE their current password with a new password.
The PTXT of the password is never reveiled.
You only compare hashes.
Yes, there is a common workaround.
Assuming that you have your users in your database.
You send the "password reset link" containing some "key" information, like a guid. An example link is a form:
http://your.site.com/setpassword?id=5b070092-4be8-4f4d-9952-1b915837d10f
In your database you store the mapping between sent guids and emails.
When someone opens your link, you check your database and you can find out who asks for the page - because any valid guid maps to an email. You can then safely let the user change his/her password assuming their email is not compromised.
When it's about to store the password, you never store it in plain text, you always hash passwords, using additional random salt to make the dictionary attack more difficult when someone breaks into your database.
There is a workaround which is less secure than a password reset but works if it is a requirement that users are sent a password, not a reset link.
What you do is you generate a new password that contains sufficient randomness to be very hard to guess, but is also formatted in a way that it is easy for them to remember and read out (say over the phone).
Something like: xyz-xyz-xyz-nnnn where xyz is an easy-to-spell but uncommon word and nnnn is a four digit number.
Then set it up so that this is a temporary password that needs to be changed on first login.
Set the password using the same logic you would use to set a normal password, so that it is correctly salted and hashed, and then send the password plaintext via email, like so.
Dear FirstName LastName,
You requested we reset your password.
Your new password is:
insipid-mirth-nonplus-9174
You will be able to log into the system once using this password, then you will need to enter a new password.
Important Caveats
This system has some serious vulnerabilities which make it unsuitable for websites where data security is crucial. There are more than these, but these are the ones I know/can think of:
Unlike systems which use a password reset link, this system could be used to lock someone out of the system (assuming you use it as is) unless you either require someone to fill out identifiable information before issuing the password reset, or send a "are you sure you want to reset your password?" email first. This would entail them clicking on a link with a GUID that goes to the server; at that point they may as well be sent to the password reset form anyway.
Since the password is being sent plain text via email, there is a danger it can be intercepted and the password can be used. Although to be fair this is not that much different than the risk of sending a password reset link.
If you ignore the risks in step #1 and you don't use a sufficiently random way of generating passwords (say you use a word list of fewer than 1000 items), someone who has hacked into your server will be able to retrieve the salted password hash and then write an algorithm that generates all possible passwords and checks them against the hashed password. Not as much of a problem if you use a cryptographically complex hashing algorithm.
If you want to send password to user via Email in cleartext and want to store those password into database as hash or any other format . It will be possible.......
Just you will have to follow some simple way....
1 .you will have to take those password as variable which will send from user.
2. When you store database then just convert it as you wishes format.
3. But when you send those to user by mail , That time just sent those variable password...
I think it will be helpful to build your concept about WAY.......
I'm trying to secure a website that is being moved to a public server soon. I've just finished adding the password hashing functions to all of my login scripts. I'm using FormsAuthentication.HashPasswordForStoringInConfigFile(pw, method) to do so. I have a question about the process I'm using and whether or not it's secure for a web server:
Password is sent in plain text over HTTPS to the server
The server looks in the Users table to find the user's Salt (several random characters) and their hashed and salted stored password
The plain text password is appended with the Salt
The new string is hashed using the above function
The newly hashed version is compared to the stored version
If equal, login is allowed
If not equal, the login attempt is logged in Session variables, up to 3 times before locking out the user's machine from accessing the login page until an admin verifies IP address and unlocks.
Does this look about right? I just don't see how the salt is effective in this method... Anyway, all I've done is add a salt and hash. Is this considered Encryption? Or am I missing a step? I remember reading that hashing algorithms like SHA1 and MD5 are not encyption algorithms, so what else needs to be done?
That is correct. The salt is used to prevent rainbow table attacks where a dictionary of common works hashed with MD5 is used to try to gain entry. Using the salt ensures that even if they had an MD5 hash of the word, it wouldn't work because they don't know the salt.
The MD5 algorithm is a 1 way hash algorithm, and not an encryption value. The difference is, once you've hashed the value, there is no way to get back to the original value. Encryption allows you to decrypt the data and get back the original value. So you are correct, they are not the same, and your passwords are not encrypted, they are hashed. This means that if someone forgets their password, you cannot send it to them. You have to provide a way for them to reset their password instead. This also means that anyone with access to the database would not have access to raw passwords. Which is good because a lot of people use the same password everywhere, and if you had access to a large list of usernames and passwords, someone could decide to start trying to log into bank / credit card websites.
What you are doing is a recommended practice.
You shouldn't be storing the retry count in the session - an attacker could simply discard their session cookie after each attempt, allowing them to retry as many times as they wish. Instead, store it against the user record.
So I'm making a website for a game. Nothing that will get popular :P
Right now I'm thinking about password security, I'm gonna use salting but
instead of adding a new column in account table I was thinking about using the account name as salt since it cant be changed, and is "unique". I mean 2 users cant have the same account name.
But I was thinking how safe it would be if lets say someone has the account name banana. I mean that word gotta be popular in these wordlist hackers use.
Lets say the account name is banana and the password is hello (hashed with sha1), that would be pretty easy to reverse am i right?
No, you should follow standard practice and generate a new unique salt per user, and just store it right along side the other fields in the database, it's not hard to do.
The hacker can lookup the sha digest in the rainbow table and find that it matches the input 'bananahello' (considering that 'bananahello' is something already in the vehiculated rainbow tables). He can see that the user name is 'banana', ergo the password is 'hello'.
I would hash something similar to HTTP Digest HA1 hash: sha1(username . realm . password). Now a rainbow table customized for your realm ('example.com') is pretty hard to come bye. A side benfit is that you can actually implement Digest authentication on your site, which is sooo much better than Basic and forms.
It would be preferable to not using a salt, but would not be as secure as a random salt.
At least computationally permute the username somehow known only to you to get the salt. While hashes are not easy to reverse, you want to protect yourself against brute-force attacks. If you use the un-permuted username as the salt, you have made it easier to break with a dictionary attack.
There's no risk. The usernames are public knowledge anyway. And the hash is never easy to reverse - that's the whole point of hash.
As for the dictionary attack, you protect against it by having a password complexity policy.
Edit: yeah, to prevent a rainbow attack just prepend the salt with a longish arbitrary string. SHA1("whooooohooomysiteisthebest_bananahello") is not likely to be in a rainbow table.
Salting just prevents pre-calculated attacks. It's possible to have rainbow tables with dictionary salts already calculated, and it still doesn't prevent traditional bruteforcing, which will stumble across Remus's example of "bananahello" example pretty quickly.
By using public usernames verbatim, you've removed the value of the salt, the only task would be to calculate a rainbow table for that known salt. So to answer your question, yes, your implementation would be easy (but maybe not quick) to reverse.