0

According to docs:

To hash a new passphrase for storage, set salt to a string consisting of [a prefix plus] a sequence of randomly chosen characters ...

and

In all cases, the random characters should be chosen from the alphabet ./0-9A-Za-z.

Reference

Why so?

Also, why the length of that random character sequence is also limited?

One-way function    Prefix  Random sequence
SHA-2-512           ‘$6$’   16 characters

Reference

Anthony
  • 103
  • 3
  • Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. – Community Jul 03 '22 at 21:02
  • The specific problem is that gnu libc is insecure by design. Here l've asked, why so? This question is very specific. – Anthony Jul 04 '22 at 09:57

1 Answers1

1

The salt is limited to those characters because those characters were the original characters supported by the DES-based crypt implementation. That algorithm doesn't accept passwords longer than 8 characters and is no longer considered secure, but that's why the characters were originally chosen. They are essentially a variant of Base64 encoding.

I can't speak to why specifically that size of salt was chosen, but it probably involves a fixed-size buffer in the original implementation. If you're using a recent Debian system, then you'll be using libcrypt instead of the glibc implementation, which supports substantially more algorithms, all of which support larger salts. For example, bcrypt supports 128 bits of salt, and scrypt and yescrypt support up to 512 bits of salt.

bk2204
  • 7,828
  • 16
  • 15