I was reading about PwdHash and it inspired me to create a little project where you input a master password and an easy to remember alias into a password hash, like bcrypt, and then you get an hash.

So far so good ; that hash should be pretty secure and no one should be able to guess my master password from it.

The problem is that this hash is not really a usable password. For example, website have all sort of requirements for password like not more than 20 characters, must contain symbol, number, lower case letter and upper case letter, must not start with a number, etc...

So : hash + requirements = usable password

But I have a concern. Is it possible that by applying the requirements to the hash in order to produce a usable password, I will lose some of the security that the hash produce?

For example, let's say the hash is 60 characters long and the password cannot have more than 20 characters. Is it bad to only take the 20 first characters of the hash? Would it be better to produce the 20 characters of the password combining together the 60 characters of the hash?

So the general question is :

How should I proceed to create a usable password from that hash? Do I have to worry?

  • A number of years ago, the place where I worked had a similar app to set and get passwords for the servers. The app combined a random string (which was the same for all servers, and changed regularly) with the server's hostname and the username of the account to which the password applied. It was secure enough for our purposes, which is not to say that it would be secure enough for everyone.
    – Jenny D
    Mar 23, 2015 at 8:29

3 Answers 3


For a good hashing algorithm (and unless you've rolled your own hash, you're probably using a good enough one), all of the bits should be pseudorandom.

A 20 character password is indeed weaker than an 60 character password, but one 20 character password is equally secure as another if they're equally random. Combining a 60 character hash into 20 characters would not add more randomness than just taking the first 20 characters.

When it comes to password design, the main threats (strategic guessing of your password, brute force, trying your password against all of your online profiles) can be mitigated by just using a different, long, random password for each website. The level of randomness provided by truncating a hashing function is enough.


Stop adding useless complexity

This would just add one step to build password...

In case of brute force, attacker could use same tool you've chosen for doing this step automatically.

In fact, this won't add a lot of work for attacker, but by adding step for users, they could even contribute to reveal password by user's mistake.

Use passphrases instead of password whenever possible.


I am not convinced on the claims of PwdHash to begin with. The idea isn't bad but their implementation sounds shaky. I would suggest coming up with your own site-specific implementation rather than using a browser extension that generates passwords for you. It's easy to do (I do it myself). The benefit of this is that you don't have to jump through hoops to make your password compatible with complexity requirements. Additionally, you aren't locked into whatever algorithm PwdHash chooses to use. If you come up with something yourself, it will always be less predictable than PwdHash on principle.

  • Are you suggesting security through obscurity? About PwdHash, I know they have a couple of flaws like : how do you change your passwords. But all that is not my question. I'm trying to find out if by applying the password requirements to the hash, I could potentially shot myself in the feet.
    – Gudradain
    Jan 22, 2015 at 5:02
  • @Gudradain Passwords are the epitome of security through obscurity. What I am suggesting is that by using a tool like PwdHash you are (1) more insecure (2) creating unnecessary problems. Jan 22, 2015 at 5:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .