This is an invalid salt.
Although the documentation doesn't say so, the source makes it clear that crypt.crypt
will return None
if the underlying C function returns NULL. POSIX allows it to do so, and linux/glibc explicitly does so when given an invalid salt.
So, what's wrong with this salt?
If you read the "Glibc notes" section on the manpage, the string $1\$WDvKY5n\$
is going to use 1\
as its encryption method id. There's an encryption method with id 1
, but nothing with id 1\
. Plus, the salt itself is WDvKY5n\
, but the salt is only allowed to contain characters in the set [a-zA-Z0-9/]
.
Most likely, you printed out the salt in some way that caused the $
characters to be escaped (for the shell?), then copied and pasted the escaped version instead of the actual string.
If that's what went wrong, just use $1$WDvKY5n$
and everything will be fine.
If something else went wrong and the salt is irreversibly garbled, just go look it up correctly and use whatever you find.
Meanwhile, the reason this works for people on other platforms (returning '$1d2n7Q0.r54s'
instead of None
) is that BSD and FreeSec crypt
(the stock implementations on most POSIX platforms besides linux) both take any salt that doesn't start with an underscore to be a traditional-crypt value, where the first two characters can be any ASCII value and the rest of the salt is just padding.