0

First note: This is on-disk usage only, never transmitted over a server.

How secure, or additionally secure, is it to sha-3 (512) a password if said password is below 128 characters, THEN proceeding to scrypt it?

Is it more secure than straight scrypting the password? Should beyond 128 be sha-3'd? Should there even be any sha-3ing of it at all?

I'm aware sha-3 is just a hashing and not the same as aes/bcrypt/scrypt/twofish etc., I am merely looking to see if some sort of addition layer can be added for even more security than scrypt offers by default.

On a note of weak password will always be weak, in this instance a file can be specified as the password (of any size within the operational limits of scrypt), but a regular password can be used as well, therefore my question arises:

How much more secure, even in a theoretical sense, if it all, is sha3-512-ing a password below 128 characters, and above 128 characters, before scrypt-ing it?

Improve this question
5
  • It could leak whether or not the hashed password was longer/shorter then your threshold based on how long the computation takes. Can we ask why sha-3 should be applied at all? As in, why do you expect this would improve security?
    – Ella Rose
    Aug 14, 2016 at 2:32
  • Because 128 character length is better than 127 character length, and not knowing necessarily whether a user used a sha3-hashed string to create the scrypt result can also make it more difficult for that route of attack.
    – Robert 'Jet' Rowe
    Aug 14, 2016 at 2:35
  • "How much more secure, even in a theoretical sense": zero. The answer is zero. It does not make it more secure. One sha-3 calculation before scrypt is like wearing your lucky hat...AND a bulletproof vest, before your best "watch this" moment yet.
    – Ben
    Aug 14, 2016 at 4:03
  • 1
    This exact same idea was asked over at the Cryptography Stack Exchange not too long ago, and I'd highlight my answer to it.
    – Luis Casillas
    Aug 14, 2016 at 4:25
  • bcrypt can't handle 128 chars in a pw, can scrypt? if not, then you are making the attack easier.
    – dandavis
    Aug 14, 2016 at 21:26

1 Answer 1

Reset to default
2

An attacker would not guess the 128 long character that goes into scrypt, they would simply guess the 127 character long password that goes into sha-3. This might not seem like a problem if the password is 127 characters long, but it's arguable that scrypt is needed in such a situation to begin with.

Using realistic measures of password length, i.e. 5-10, this discrepancy becomes larger - the adversaries work factor will be limited by the length of the actual password, not the length of the output of the sha-3 hash.

Doing this may leak whether or not the length of the password is greater or less then your threshold, due to the operation requiring variable lengths of time.

So there should not be any sha-3'ing of anything at all. Remember: adding more crypto doesn't solve the problem magically, and doing things that are not explicitly beneficial can only increase your attack surface.

Improve this answer
3
  • I see you have a note that says nothing is being transmitted to a server; That makes me question why you even need scrypt at all, unless you're using it as a key derivation function for deriving a key from a password.
    – Ella Rose
    Aug 14, 2016 at 2:48
  • Given that an attack would not know whether the password has sha3 applied before-hand, meaning the potential base password could still be anywhere between 1 and the operational limit of scrypt, does that change your opinion?
    – Robert 'Jet' Rowe
    Aug 14, 2016 at 3:06
  • And the attacker won't know about the sha-3 because...?
    – Ben
    Aug 14, 2016 at 16:40

You must log in to answer this question.

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