1

Scrypt produces a binary hash of a password. Instead of storing it as bytes directly, we are considering to store the Base64 encoding of this string.

Would that make the password hash more vulnerable in case of a leak? The password salt is generated on a per user basis.

Improve this question
3
  • The question that needs to be asked is why are you storing this as a string? Unusual storage of passwords often correlates with insecure practices elsewhere..
    – Hector
    Oct 18, 2017 at 8:11
  • This is very common, and quite acceptable, but do ensure you don't implement a feature that allows a user to manipulate the base64 values.
    – Mark Buffalo
    Nov 17, 2017 at 7:21
  • 1
    This is common and doesn't change the security property of the underlying scrypt, but it is usually suboptimal design in terms of space usage. Why can't you just change your database's column type so it can store arbitrary blob, for example bytea or bit string if you use postgres or binary/varbinary if you use mysql.
    – Lie Ryan
    Nov 17, 2017 at 12:11

1 Answer 1

Reset to default
4

If you're storing only the hash itself as base64, this shouldn't materially alter the one-way nature of the hash or its protection of the original plaintext.

As long as no other pre-hashing plaintext data or related metadata is included (that would in any way hint at potential plaintext), then a leak of base64-encoded hashes wouldn't be any easier to attack than a leak of the original hashes.

An attacker would simply analyze the data, discover that it consists of base64 strings, convert them back to their original hashes form, and then carry out the attack. This won't slow most attackers down, but it also won't make things any easier for them.

Improve this answer
2
  • 1
    It should be noted that some kinds of metadata (like work factors and salts) are sometimes included with the password digest in a single database column. This is perfectly fine from a security perspective - that data would be there anyhow, just separated by columns in the database instead of by some separator character that the data fields cannot have (for example, because it's not a base64 output character) - and you would then store those parameters-plus-hash-output-in-base64 strings into your database (or whatever).
    – CBHacking
    Nov 18, 2017 at 3:22
  • Indeed. In context, "the hash itself" would normally mean "all of the things normally associated with the format of a full hash, including work factor, rounds, salts, etc."
    – Royce Williams
    Nov 18, 2017 at 4:06

You must log in to answer this question.

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