Skip to main content
Cryptography

Return to Answer

deleted 131 characters in body
Source Link
otus
otus
  • 32.4k
  • 5
  • 73
  • 167

Your procedure seems backwards.

If you store the seed ofSo your idea is to effectively turn the password generation inauthentication into a database, anyone who gets access to the database will be able to generatekey-based authentication by deriving the same password. You still need to get it out and remember/store it, so there doesn't seem to be an advantage over generatingmachine passwords from a normalsingle random password and storing a hash of itkey stored elsewhere. This would necessitateAssuming key storage is secure (probably encrypted with a brute force or dictionary attack to find thestrong password), even if your database leaksthis is sound.

Additionally, IIt would suggest that abe better fit for yourto just use-case might be asymmetric keys – the computer would generate an authenticationasymmetric key-pair, store the public key and send you the private key for laterbased authentication built into most remote access tools (cf.like ssh), so that you don't mess up anything by rolling your own crypto.

If But if you do need to generate a normaluse password authentication, your idea is not insecure either.

Actually generating the password / passphrase from a SHA-512 hash (or any seed material), it's a fairly mechanical process:

  1. Choose the alphabet (or dictionary). For passwords you might use hex or base64, for passphrases any conveniently sized dictionary will do.
  2. Choose the bit-strength. 128 bits is sufficient, but may result in quite long passwords. OTOH, there's no use making it longer than input entropy.
  3. Consume the input bits to generate characters/words until you have a sufficiently long password. With a hashed input like SHA-512 you can just use the first bits from either end, with a non-mixed seed you should probably hash it first (with a strong password hash if entropy is low).

Your procedure seems backwards.

If you store the seed of the password generation in a database, anyone who gets access to the database will be able to generate the same password. You still need to get it out and remember/store it, so there doesn't seem to be an advantage over generating a normal random password and storing a hash of it. This would necessitate a brute force or dictionary attack to find the password, even if your database leaks.

Additionally, I would suggest that a better fit for your use-case might be asymmetric keys – the computer would generate an authentication key-pair, store the public key and send you the private key for later authentication (cf. ssh).

If you do need to generate a normal password / passphrase from a SHA-512 hash (or any seed material), it's a fairly mechanical process:

  1. Choose the alphabet (or dictionary). For passwords you might use hex or base64, for passphrases any conveniently sized dictionary will do.
  2. Choose the bit-strength. 128 bits is sufficient, but may result in quite long passwords. OTOH, there's no use making it longer than input entropy.
  3. Consume the input bits to generate characters/words until you have a sufficiently long password. With a hashed input like SHA-512 you can just use the first bits from either end, with a non-mixed seed you should probably hash it first.

So your idea is to effectively turn the password authentication into a key-based authentication by deriving the machine passwords from a single random key stored elsewhere. Assuming key storage is secure (probably encrypted with a strong password), this is sound.

It would be better to just use the asymmetric key-based authentication built into most remote access tools (like ssh), so that you don't mess up anything by rolling your own crypto. But if you need to use password authentication, your idea is not insecure either.

Actually generating the password / passphrase from a SHA-512 hash (or any seed material), it's a fairly mechanical process:

  1. Choose the alphabet (or dictionary). For passwords you might use hex or base64, for passphrases any conveniently sized dictionary will do.
  2. Choose the bit-strength. 128 bits is sufficient, but may result in quite long passwords. OTOH, there's no use making it longer than input entropy.
  3. Consume the input bits to generate characters/words until you have a sufficiently long password. With a hashed input like SHA-512 you can just use the first bits from either end, with a non-mixed seed you should probably hash it first (with a strong password hash if entropy is low).
Source Link
otus
otus
  • 32.4k
  • 5
  • 73
  • 167

Your procedure seems backwards.

If you store the seed of the password generation in a database, anyone who gets access to the database will be able to generate the same password. You still need to get it out and remember/store it, so there doesn't seem to be an advantage over generating a normal random password and storing a hash of it. This would necessitate a brute force or dictionary attack to find the password, even if your database leaks.

Additionally, I would suggest that a better fit for your use-case might be asymmetric keys – the computer would generate an authentication key-pair, store the public key and send you the private key for later authentication (cf. ssh).

If you do need to generate a normal password / passphrase from a SHA-512 hash (or any seed material), it's a fairly mechanical process:

  1. Choose the alphabet (or dictionary). For passwords you might use hex or base64, for passphrases any conveniently sized dictionary will do.
  2. Choose the bit-strength. 128 bits is sufficient, but may result in quite long passwords. OTOH, there's no use making it longer than input entropy.
  3. Consume the input bits to generate characters/words until you have a sufficiently long password. With a hashed input like SHA-512 you can just use the first bits from either end, with a non-mixed seed you should probably hash it first.