informatikr / scrypt Goto Github PK

When discussing cdepillabout/password#15
@Vlix noticed, that scrypt probably has the same security issue.

Maybe you wanna have a look into it. I‘ll elaborate more if you have any questions.

Would be nice if scrypt was part of stackage, so that I didn't have to include it in extra-deps.

There is practically no effort needed on your side (I have a few packages in stackage myself). Plus, you'll automatically be notified when your package fails to build with newer versions of its dependencies (as you don't have any upper bounds).

The functions encryptPass, verifyPass, etc. ignore trailing NUL characters in passwords, so the passwords "foobar" and "foobar\NUL" are treated as equivalent -- the password "foobar" will successfully verify with scrypted password "foobar\NUL" and vice versa. NUL characters appearing elsewhere in passwords are respected, so "foobar" and "foo\NULbar" are not treated as equivalent. Nor are "foo" and "foo\NULbar" treated as equivalent, so it doesn't appear as though passwords are simply being truncated at the first NUL.

The following program demonstrates the bug. It inserts a NUL character inside the string "foobar" in a few different positions, and outputs cases where two distinct password strings (e.g. "foobar" and "foobar\NUL") are treated equivalently.

http://lpaste.net/7630761935448834048

This behavior occurs with the scrypt-0.4.0 package on Hackage.

Granted, it's probably unlikely that someone would put a NUL inside a password, but it could conceivably happen for randomly-generated passwords for machine-to-machine authentication, where typeability isn't a concern.

Currently, only x86* is supported due to SSE. It would be nice to enable it for other archs too.

Haskell Platform 2012.4.0.0
<sys/mman.h> doesn't exist on Windows/mingw.

To fix, just remove the line

#include <sys/mman.h>

from crypto_scrypt-sse.c. The package then compiles correctly. Tests pass.

Is there a reason why bufLen is static at 64?

When trying to build a static library that includes this package as well as linking openssl, you end up with duplicate symbols, for the following symbols:

• SHA256_Init
• SHA256_Update
• SHA256_Final

as they are defined in openssl and this package.

Basically, having one libscrypt makes things easier. Otherwise, improvements in one binding don't get propagated upstream to others, etc, etc.

Also, I'm open to placing these bindings in the readme, cabal install scrypt and author attribution at your option... up to you.