Creating a form with password we can obligate users to insert a password that complaints a regular expression. But is it a good idea to ask for this requirements? Something like to have at last 8 characters, 2 special simbols, 2 numbers, etc...
What I mean is that maybe sign ups can increase if we let users free to write the password they wish with no restrictions.
Can someone explain me if in this case there are security issues?
Related
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
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'm creating a Rails 3.2 app at the moment and I'm trying to make it so that it's as simple as possible for a user to log in, preferably only using a 4 digit-code.
I was thinking about creating a subdomain for each user, and then just limiting the password to four digits and make it numerical only (which I guess would work).
However, I don't really need such a complicated set up, all the users will see roughly the same thing, and there's no private information between users, it's simply to save time logging in, so they don't need to bother with a username.
Does anyone have any suggestion about how I could do this and then implement it?
Any help is greatly appreciated.
Why not just use there email address on login? I wouldn't not limit how complex the password is. This should be very easy with devise.
Another point that is should be made is that a 4 digit number is not secure at all. There is only 10,000 passwords to choose from. Very easy to crack with the proper software.
The solution: Just use email and password. Simple to do and a Internet standard.
How do banks authenticate users just by asking some letters of the password. Does is mean that hashes of those individual words are stored in the database, and if yes then would not it make it very vulnerable to break those passwords. Can you please give me some insight in how they do it.
Thanks
It does not matter if they hash this information or not. This way of proceeding is totally unsafe and makes the system very weak. So, the way they do it is really the 'wrong' way.
Just wondering if there are more password policies beyond the generic ones such as "minimum password age", "password must meet complexity requirements", etc. I would like to create stronger password policies for the administrators. Is there a way to add more complexity to the password requirements?
Another thing, is there a way to prevent users from doing stuff like this:
old password: password1 (expires...)
new password: password2 (expires...)
etc.
We find that a lot of users are just adding a new number to the end of their password.
Thanks in advance,
Matt
We find that a lot of users are just
adding a new number to the end of
their password.
This is a well known problem with password complexity and, especially, ageing requirements - they often reduce security as people will write down passwords as they can't remember them. If your users are doing this then it's a good indication that you are expiring passwords too quickly.
See also: Password complexity strategies - any evidence for them?
Password strength and usability are often at odds these days. If you're part of a forward thinking organization, the best technique that I've found is to encourage users to make use of applications that both solve your problem and theirs, such as Password Managers. KeePass and Password Safe are two such applications, but there are many others. Here is the new policy:
Encourage users to create 1 strong password that they own and maintain which is the password to their local/private encrypted database.
Ask them to use the built in functionality for generating random, strong passwords.
Encourage them to simply use the copy/paste functionality from the password manager to your application
There are several pros / cons to this approach; but believe me, users are happier when they don't have to deal with all of the unfriendly nonsense required by passwords these days AND they might actually stop short cutting your policies.
Just wondering if there are more
password policies beyond the generic
ones such as "minimum password age",
"password must meet complexity
requirements", etc. I would like to
create stronger password policies for
the administrators. Is there a way to
add more complexity to the password
requirements?
Minimum and maximum password age, password history (goes with the minimum age), a one-time pad, a crypto-based approach using crypto hardware like tokens or smartcards, .... lots of security options.
If you just want to make the password itself more complex, ... just decide what your goals are (e.g. want to avoid being in rainbow tables, want to make an attack take at least X hours/days/weeks/months) and chose your complexity requirements based on that.
If you say that the password must contain letters, numbers, symbols, be at least 16 characters, and have no words in it (including leeted words), you're probably reasonably safe, except for the fact that your admins have written the password down and put it under their keyboard.
Another thing, is there a way to
prevent users from doing stuff like
this:
old password: password1 (expires...)
new password: password2 (expires...)
etc.
We find that a lot of users are just
adding a new number to the end of
their password.
This one is easy. It is common to combine a minimum password age with keeping N historical (but definitely NOT the current password) passwords in cleartext to prevent people from re-using the passwords quickly. Simply decide how different new passwords must be, and check the edit distance of the new password from each historic password.
As Colonel Sponsz pointed out, there is some research data suggesting that these policies usually make matters worse.
I would suggest experimenting with some free tools like stateless password generators (e.g. Getpass) as they generate highly complex (for modern standards) passwords by default. Also, unlike cloud password managers, they don't store passwords or any other client data. They are free and open source.