I am implementing ASP.NET Membership, using default SQL Provider, default web.config settings.
I notice that passwords are hashed. But I don't know how asp.net hash my passwords, so I am not sure whether it is possible for a hacker to decrypt this?
If asp.net use the same rule to hash password, which everyone knows. than a hacker can easily crack it.
for example. If asp.net use MD5(123456), which result is "E10ADC3949BA59ABBE56E057F20F883E", then a hacker may have a MD5 Dictionary to look up this.
My settings is:
<add name="AspNetSqlMembershipProvider" type="System.Web.Security.SqlMembershipProvider" connectionStringName="ApplicationServices"
enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="false" requiresUniqueEmail="false"
maxInvalidPasswordAttempts="5" minRequiredPasswordLength="6" minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="10"
applicationName="/" />
-- SQL Statement:
SELECT am.UserId, am.[Password], am.PasswordSalt FROM aspnet_Membership am
-- The result is:
F10A635D-22DA-419C-84E6-767D2A35A010,tpeiwPt5+kFbcocQZOuc4aoHeuI=,PVq9dPtbFxze9Erbfd7HrA==
The password is 123456, it become "tpeiwPt5+kFbcocQZOuc4aoHeuI=".
Is this value always the same on different machines or different apps?
If this value has something to do with the salt "PVq9dPtbFxze9Erbfd7HrA==", is it possible for hackers to use this salt to decrypt my password?
To be able to answer this question, you have to understand two things: the role of hashes, and the role of salts.
The point of a hash is to distill an arbitrary string into a string of known length in a one-way process. That is, a good hash algorithm will do this in a manner such that it is a hard problem to find any string that hashes to the same value.
However, the problem is that hash algorithms always return the same result when given the same input. The point of a salt is to mitigate this problem in the event that the password database is stolen. Every time I hash a password, I generate a completely random salt, which need not be secret, and prepend it to my password before hashing it. This way, I ensure that every time I hash a given password, I obtain a different result. The reason that the random salt need not be secret, and in fact must be stored in 'plaintext' along with the hashed password, is because the same salt used to generate the original hash is required to verify, for authentication purposes, that a given password matches the hash.
Because a good salt is randomly generated every time a user wants to change a password, even re-storing the same password will almost surely create a completely different hash, as long as the application storing passwords makes proper use of salts.
If the hash algorithm is well-constructed, then the only attack possible against passwords stored with random salts is a brute-force search. Some hash algorithms like MD5 are considered 'broken', in that it is possible to find so-called 'hash collisions' in faster than brute-force time. You will want to find out which algorithm your platform is using to generate password hashes, and read up a bit to find out if hash collisions can be found for that algorithm.
Related
I'm using the golang.org/x/crypto/bcrypt package for storing passwords. Looking at documentation and other SO questions, it seems like I'm not supposed to (or at least don't have to) generate a salt for the password before I generate the hash. This seems counter to everything that I've read about cryptography and modern password storing, and makes me a bit nervous. Is it really secure enough to just pass the user's normal password into bcrypt.GenerateFromPassword, or am I reading things wrong?
The bcrypt package generates the salt for the application. The return value from GenerateFromPassword encodes the cost, salt and hash of the password.
okay I am trying to make a log in form to my website in C# it has md5 + salt.. the problem is salt. md5 I can make work but salt just won't work. I made a php that gets the user name, user group id's etc. I have removed tons of instances of salt in the db and it either destroyed log in, or just did nothing. I am wondering if there is an easy way to remove salt?
What do you think is the purpose of the salt? If you could easily remove it, what would have been the reason to add it? You should really take a few minutes to read a tutorial about password hashing.
MD5 is not an appropriate choice to hash passwords, because it is ways too fast. One can calculate 8 Giga MD5 values per second with common hardware nowadays, that makes brute-forcing too easy. Instead use a slow key derivation function like BCrypt or PBKDF2.
To answer your question, you need the stored salt to verify the user entered password. If the user enters the password for login, you calculate a hash with the same salt you used to calculate the stored password in the database, then you can compare the hashes.
What is safer?
I can use either one as I'm using CodeIgniter, but with Sha1, I can't reverse if I ever needed to for some odd reason like I can with encryption.
But I'm still somewhat new to PHP, so if there is a way I can possibly do something like display the sha1 hashed password as stars, so if say your password is "lala123" it would show this to me: "*******" and never ever be able to be shown "lala123", is it possible to do that with sha1? If so, please help me, otherwise I'll use encryption, but only if it's safe to use for passwords. Please let me know :)
Hashing is considered more secure for the very reason that even you cannot restore the password. If you password database is compromised, and the password encryption is reversible, the baddie might decrypt them, especially if the code that does the decryption has been compromised as well. SHA1 is not reversible by design.
You're not supposed to display the password in the UI - ever. The * are just that - an arbitrary number of stars. Disclosing the length of a user's password constitutes in itself a considerable hint to a would-be guesser.
Neither. You should use hashing to keep the passwords secure in case someone gets the password database. But the consensus answer seems to be to use bcrypt, described in this answer. It is a hash function based on blowfish with variable cost so you can tune security versus performance.
This is for a college assignment. At our College they use Microsofts's Active Directory to run their network.
Every month we get asked to change our passwords and when we do so it won't accept any of the previous five passwords we have used, or similar passwords. For example if my password was 'secretpassword1', next month I couldn't use 'secretpassword2'.
However the only way that I can see this being done is if there is either a flaw in the hashing algorithm used to store the passwords; the passwords aren't hashed but encrypted; or worse they are stored in plaintext.
After a quick Google-Fu session it appears that Active Directory will store passwords in regular Windows hashes. So can anyone explain this?
Cheers
P.S. This may be our imagination; perhaps you can reuse a password that is slightly different?
The old passwords are stored (in hashed format) in the AD database. As part of the password change process, this gets checked and/or updated.
It's easy to do if you generate the variants from the new password, not the old password.
Imagine an algorithm that takes a password, and generates a few hundred simple variants of it. So for an input like password1 it would generate the following variants:
PASSWORD1
PasSSword1
password2
password
P#aaW0RD2
....
and a few hundred others. (Note that one of those variants is "password".)
Password crackers have algorithms like these and use them against word dictionaries to generate guesses.
Using this algorithm, we can perform the following steps:
a user sets their first password to be "password".
The system stores hash("password"), and uses this hash to compare whenever a user logs in.
Several weeks later, the user changes their password to "hunter2". The current password hash is changed to hash("hunter2"). hash("password") is stored in the list of N historical password hashes.
Several weeks after that, the user attempts to change their password to "password1". During this change attempt the following steps are performed.
3a) the new password is available in the clear, because the user just entered it. "password1" is used as input to the variant generation algorithm described above. A few hundred variant passwords are generated (in the clear).
3b) for each variant password, the hash of that password hash(variant) is calculated, using the salt for each old password. As noted above, one of the variants of "password1" is "password", so in our list of variant hashes we will have hash("password"). We end up with V variant hashes to test for each old password, V*N hashes total.
3c) The correctly salted version for each variant hash is tested against the current hash, and the previous hashes, for a total V * N binary array comparisons.
3d) One of the variant hashes is hash("password") and one of the stored N historical hashes is also hash("password"). These hashes match exactly, so the password is rejected.
This technique requires V*N hashes to be generated, where V is ~500 and N is ~10. This will only take a few seconds (even with PBKDF2, bcrypt or scrypt) and can be easily performed without disk access.
A note on salt: Changing the salt whenever you change the user's password (which you should definitely do) does make things a bit harder, but you still only need to generate a linear number of hashes, no matter how big your salt is.
Upfront, I'd like to confess to being a complete newbie to cryptography and password security. I'm trying to store passwords in a database being babysat by ruby. My understanding is that plaintext passwords should be appended to a random "salt" and that whole phrase should be hashed by some hashing algorithm such as:
Digest::SHA1.hexdigest(salt_plus_plainpassword)
Once that string is stored in the database, how does one get it out again to verify that what the user entered is correct if there was a now unknown random salt appended to it?
The best way to do it is to store the salt is one for each user and it is generated based on the Time at the point they did it.
It's true that once a person has access to your database they can see the salt for users, but if this has happened you have bigger things to worry about.
The way you check your user's password is that you take their clear text input and crypt it with the salt and then compare the crypted_passwords, if they match they are authenticated. I don't believe that storing the salt is an issue as you will need it. If you are worried about SQL injection attacks you are better off securing your application against them rather than not storing information you need, in this case each users salt.
Theoretically the salt serves two main purposes. The first is to prevent duplicate passwords to end up with the same hash value on the database. The second is to increase the length of the password, thus also increasing the difficulty of an attacker guessing a password.
But there is the problem of storing the salt, if you insert it on the database the second purpose is somewhat defeated in case someone grabs that data, ideally it should be stored on a different location, but this is only necessary if your application is very sensitive!
If the code of your application is not public, I'd say a possible way to circumvent this issue is to generate the salt based on a static value of each user, like the creation date or username, because if someone reads the database it is unclear whether or not you use salt...