New answers tagged

1

One difference is that with simple concatenation two different salt-password pairs could lead to the same hash input. For example: H('abcd'||'example@example.com') = H('abcde'||xample@example.com). This cannot happen between your password hashes if you use a constant width salt, but could still happen between your password hashes and those of some other ...


1

While it is well known that hash1(hash2(x)) only serves to increase collisions, Collisions essentially do not matter at all for password hashing. You will only lose entropy to collisions if the input entropy is near the size of the hash output. And in that case you are well and truly out of the realm of what can be cracked for any popular hash function. ...


2

A password manager that produces 16-character passwords is sufficient for most cases. Users who go for 100-byte passwords are usually overly-paranoid, since the actual security benefit is outweighed by the inconvenience. Therefore, limiting a password to 72 characters, while in theory reducing the number of possible passwords, is still very reasonable. ...


2

The reason reusing passwords is a bad idea is that the security of all your accounts relies on the security of the weakest account which uses the same password. If you sign up for PNC Bank and [favorite show here] Fan Club using the same password, one of them being compromised will compromise them both. That being said, under the assumption that one of ...


2

The approach you describe is very much like the approach that is used in the masterpassword app (http://masterpasswordapp.com/). Roughly they generate a password for each site depending on: Your master password The site name A number (so that if you have to change your password you can just increase the number) Some salts that they decice. And then they ...


4

Is there any problems from using the approach I am suggesting? Yes, there are several. First of all, some sites generate first time passwords, or even long time passwords. You may want to store those too. What if a site requires frequent updates? If one password is reversed, you'd still loose confidentiality. Would it actually be less secure if ...


1

@Jeroba88 your idea of using a hash function rather than just appending the service name to your secret password is simple yet crucial to achieve what you have set off to do. Some level of customisation (be careful), such as using PBKDF2 (or Scrypt) in place of just a plain HASH(Password|Service) (especially since it's probably preferable to use ...


2

There are several different scenarios to consider. If you assume all the sites/apps do things right, use a strong password hash, stay uncompromised, then no one should be able to find your master password anyway (unless it is a very poor low entropy password). So how or whether it is combined at all does not matter. More likely, you are interested in ...


3

In the context of most Password Managers that use encryption, you will generate a Master Data Encryption Key (MDEK) which will serve to encrypt all the passwords and the user's password would be the Key Encrypting Key (KEK) to encrypt the MDEK. This way, the MDEK stays the same when you change your Master Password derived KEK that wraps the MDEK.


1

Encrypting the salt is actually equivalent to just using the cipher as an initial step. That is, you could redefine the scheme as follows: tmp := D(hash(password), salt) password_hash = F(password, tmp) output := salt, password_hash Where D is the decryption function and F is the actual iterated password hash you defined. The addition of the cipher is ...



Top 50 recent answers are included