We are writing new applications and in requirements there are some rules about passwords:
cannot contain 6 repeated pharses in a
row
cannot be the same as last 6 passwords
Second point is easy because we have hashes of this passwords but how can we check 6 repeated pharses?
Example:
first password: kotek123
second password: kot453
how can I check subsequence if I just have hash of this passwords? Is it even possible?
How work masked passwords, I mean when password is kotek123 then some banks just want k#t##23 to log in? Do they store hashes of all possibilities?
perhaps, you should store all subsequences and check if any of them have occured in the previous six passwords.
So it's possible, but very uncomfortable for clients and for developers as well . I wouldn't like to use such a system.
Recently we had the same problem in our system, but we didn't want to poison our lives, so we check similarity of last and new password. It looks simple to do, because, usually, when user wants to change the password, he have to give both passwords, last and new.
I'm curious what method you will apply
I don't think this is possible, if you only have the hash value. This is exactly the goal of hashing a password.
By the way, in the example, the passwords are very different. I recomend just using long passwords, with special characters, and check that on the password creation.
I think masked passwords just store some characters in the database
Related
I am developing my first web app that requires a login, and it has come to the point when i must decide how to store the passwords. I have been doing a lot of reading on the proper way to hash the password and adding a salt. It occurred to me that most of the ways that are recommended would rely on some variation of information that is stored in the database with the password hash, be it some variation of using all or part of the username as a salt or some other random value.
Instead I was thinking of using the user own password as a salt on the password. Using an algorithm to jumble the password and adding it to itself in some way as the salt. Of course this to would be compromised if an attacker got access to both the stored hashes and the source code of the algorithm, but any salt would be compromised in such a situation. My application really probably does not need this level of security, but it was just something that i started to think about when reading.
I just wanted to get some feedback from some more experienced developers. Any feedback is appreciated.
If you derrive the salt from the password itself, you will loose the whole benefit of salting. You can then build a single rainbow-table to get all passwords, and equal passwords will result in equal hash-values.
The main reason to use a salt is, that an attacker cannot build one single rainbow-table, and get all the passwords stored in your database. That's why you should add a random unique salt for each password, then an attacker would have to build a rainbow table for each password separately. Building a rainbow-table for a single password makes no sense, because brute forcing is faster (why not just stop when the password was found).
Don't be afraid to do it right, often the programing environments have support to create safe hashes and will handle salting for your (e.g. password_hash() for PHP). The salt is often combined with the hash for storing, that makes it easy to store it in a single database field.
I wrote a small tutorial about securely storing passwords, maybe you want to have a look at it.
Simply duplicating the password may still be vulnerable to dictionary attacks, e.g. the password "hello" becomes "hellohello", and thus might be part of a dictionary.
Using a scrambled password as the salt enables the attacker to use a dictionary and then generate a rainbow table for all entries by adding the scambled password on every entry.
Why change a proven algorithm which can be understood by any developer? Just do it the default way and your code will be maintainable by anyone else.
"My application really probably does not need this level of security" - until that point in time it was hacked. Use a salt, it takes almost no additional effort. Do it now.
"eliminate the need of storing the password salt at all": the salt can be very small (6 bytes). It will hardly affect performance.
I just wanted to get some feedback from some more experienced developers. Any feedback is appreciated.
John Steven of OWASP performed an analysis, including threat modes, for password storage system. It explains the components and their purpose, like the hash, the iteration count, the salt, the HMACs, the HSMs, etc. See the Secure Password Storage Cheat Sheet and Secure Password Storage paper.
Cracking is not the only threat here. More than likely, the guy trying to break into your organization is going to be using one of the top passwords from the millions of passwords gathered from the Adobe breach, the LinkedIn breach, the Last.fm breach, the eHarmony breach, the <favorite here> breach.... For example:
25 most-used passwords revealed: Is yours one of them?
The 30 Most Popular Passwords Stolen From LinkedIn
Top 100 Adobe Passwords with Count
Why bother brute forcing when you have a list of thousands of top rated passwords to use?
So your FIRST best defense is to use a word list that filters a user's bad password choices. That is, don't allow user's to pick weak or known passwords in the first place.
If someone gets away with your password database, then he or she is going to use those same password lists to try and guess your user's passwords. He or she is probably not even going to bother brute forcing because he or she will have recovered so many passwords using a password list.
As I understand it, these word lists are quite small when implemented as a Bloom Filter. They are only KB in size even though there are millions of passwords. See Peter Gutmann's Engineering Security for an in depth discussion.
I was reading that the designers of UNIX password algorithm used a 12 bit salt to modify the E-table of the unix hashing function (the DES).
Supposing i have a system with 2^(24) users?
Is that ever possible to user dictinary attack? and if so how long would it take? years??
I am really new on computer security
sorry editing: I am not sure what unit time i guess i have to assuming bytes per minute depending on my code?
The reason I am asking is for a project where one of the questions states:
"Consider a system with 2^24 users. Assume that each user is asssigned a salt from a uniform random distribution and that anyone can read the password hashes and salt for users." WHat is expected time to find all users' passwords using dictionary attack?"
thanks very much
Sounds like a homework question that is expecting a formula as an answer. Way too many things unspecified. In particular, a dictionary could be precomputed with all possible salts (2^12 = 4096, not that big) for one password. If all 2^24 users used that same one password, then every password would be in the dictionary and the question is what is the expected time to do 2^24 lookups into a table of 4096. On the other hand, if none of the users passwords are in the dictionary, then you will never find the password using a dictionary attack unless you stumble upon a hash collision.
Probably better asked on security.stackexchange.com
My co-workers are using a commercial program that encodes and stores login passwords on some database.
Now, I'm developing another program to achieve some other tasks, but I want my co-workers to authenticate to this program with their same username and passwords to avoid confusion.
The problem is, I don't have (and probably never will) any source code to determine which encryption algorithm they've used.
I ran some tests and observed that same passwords always produces same hashcodes with 24 characters in length. For example;
1 XeVTgalUq/gJxHtsMjMH5Q==
123456 0Q8UhOcqClGBxpqzooeFXQ==
Is there any way to determine which algorithm they've used ?
Thanks in advance,
Nope. That is the point of encryption / hashing-- it is supposed to be opaque so that it should not be easy to reverse engineer. The only thing you can do is try a few well-known hash algorithms like SHA-1 and see if the hash values match the other program. But, there's no way to know if the other program added in any "salt" or is hashing together multiple things, e.g. username + password or some other scheme. So you are probably out of luck on that front.
One idea you could try with your new program: if the user has never logged in before, allow them to log in the first time with ANY password. Tell the users that they should use the same password they did with the other program. Then, when they log in, capture that value and hash it using your own hashing scheme, then store that for future logins. So ultimately you would get the result you're aiming for (that users can use their same passwords), without having to reverse engineer the encryption scheme of the other program.
Now, clearly the drawback with this approach is that it is not secure at all for the first login. Someone could hijack another user's account if they logged in as that user before the real user had a chance to log in for the first time (and thereby lock in his password). So this is only an option if there is no sensitive data pre-loaded in the new program that could be compromised. Also you would need the ability for an administrator to reset a users' password so that if this kind of thing did happen, you could correct it easily when the real user reports that they can't log in.
In the official documentation of the PKCS5 V2.0 standard, we can read "The salt can be viewed as an index into a large set of keys derived from the password, and need not be kept secret."
The part "need not be kept secret" is interesting.
Since the salt is used to add a huge range of password possibilities (or to create two different keys if two users had the same password), what is the purpose of letting the salt insecure?
I understand that typically, an attacker wont have access to the salt, so it will complicates his job to find the right password. But if an attacker knows the salt, where is the "magic"? Knowing the salt is like perform a traditional dictionary attack (if we exclude the iteration count)!
Is there something that I dont understand? I know that knowing the salt dont break the security but, saying that it "need not be kept secret" sounds strange to me.
The rest of the paragraph (in the standard) seems to explain it:
... Although it may be possible for an
opponent to construct a table of
possible passwords (a so-called
“dictionary attack”), constructing a
table of possible keys will be
difficult, since there will be many
possible keys for each password. An
opponent will thus be limited to
searching through passwords separately
for each salt.
The point is that you can't just take a list of passwords (let's say 77 million passwords) and run them through the same tables. You will need to build a separate table for each password + salt.
Wondering whether it matters if a salt is unique for a single given user each time the password is changed, or whether it's not a big deal to reuse the same salt each time.
I currently generate a new random string as the salt each time a given user updates the password. This way each time the user has a new password their is also a salt change. It's easy to do, so why not.
Well... here's why. I need to store the previous X passwords to ensure a password is not reused. In the old days (the last time I wrote code for this), I could just store previous MD5 hashes, and compare new ones to that list. Well, now that I am using salted hashes where the salt is unique each time, those comparisons are no longer possible as the previous salts are no longer known.
To make that system work, I have two choices: store a history of the salts in addition to the final hashes, or reuse the same salt for any one given user with each password update. Either of these would allow me to build values that could be compared to a history.
The latter is less work, but does it lose any strength? From a practical standpoint, I don't see that it does. Thought I'd get a second opinion here. Thanks.
To keep the question "answerable" -- would reusing the same salt for any one user have an acceptably minimal reduction of protection in order to maintain a searchable password history (to prevent pswd recycling)?
Reusing the same salt means that if a user is explicitly targeted by a hacker, they could produce a "password to hash" dictionary using "the user's salt" - so that even if the user changes their password, the hacker will still immediately know the new password without any extra work.
I'd use a different salt each time.
As for storing the MD5 hash plus salt - presumably you're already storing the salt + hash, in order to validate the user's current password. Why can't you just keep that exact same information for historical checks? That way you can use one piece of code to do the password checking, instead of separating out the current and historical paths. They're doing the same thing, so it makes sense for them to use the same code.
EDIT: To explain what I mean, consider a 4 character salt, prepended to the password... and for the sake of argument, imagine that someone only uses A-Z, a-z and 0-9 in their password (and the salt).
If you don't know the salt ahead of time (when preparing a dictionary attack) then in order to prepare a dictionary for all 8 character "human" passwords, you need to hash 62^12 concatenated passwords. If, however, you always know what the first 4 characters of the concatenated password will be (because you know the salt ahead of time) then you can get away with only hashing 62^8 values - all those beginning with the salt. It renders the salt useless against that particular attack.
This only works with a targeted user of course - and only if the attacker can get at the hash list both before and after the password change. It basically makes changing the password less effective as a security measure.
Another reason for using salt in password hashes is to hide the fact that two users use the same password (not unusual). With different hashes an attacker won't see that.
Firstly, stop using MD5 (if you are using it), and use SHA-2, MD5, SHA-0, and SHA-1, are all dead hashes.
-- Edit:
I now agree with Jon Skeet, and suggest you consider generating a new salt with each password change. It covers a small case where the attacker may get the salt+hash, then not be able to gain access again, but will still allow him (with some guessing of how you combine them), to calculate what the hashes could be for all future passwords. It's very small, and is not so important, because the password sizes will need to be significantly small (say, 8 chars) for even calculating them all offline to be practical. Yet it exists.
Secondly, to consider whether or not it matters, we need to think about the purpose of salts. It is to prevent offline attacks against someone who has a complete listing of only the passwords.
On this basis, if the salt is equally "difficult" to obtain before and after password changes, I see no use a new salt (it's just as at-risk as it was before). It adds additional complexity, and in implementing complexity is where most security problems occur.
I might be being incredibly dim here, but, where would you store the salt that would be inaccessable to someone with enough access to get the hashed password.