jvarho / pylibscrypt Goto Github PK

scrypt for python

License: ISC License

Python 97.57% Shell 1.12% Makefile 1.03% Dockerfile 0.28%

python scrypt password-hash

pylibscrypt's Introduction

Scrypt for Python

There are a lot of different scrypt modules for Python, but none of them have everything that I'd like, so here's One More1.

Features

Uses hashlib.scrypt on Python 3.6+ and OpenSSL 1.1+.
Uses system libscrypt2 as the next choice.
If neither is available, tries the scrypt Python module3 or libsodium4.
Offers a pure Python scrypt implementation for when there is no C scrypt.
Not unusably slow, even in pure Python... at least with pypy5.

With PyPy as the interpreter the Python implementation is around one fifth the speed of C scrypt. With CPython it is about 250x slower.

Requirements

Python 3.4+. Equivalent versions of PyPy should also work.
For Python 2.7.8+ support install the latest version 1.x instead.
If you want speed, you should use one of:
- Python 3.6+ with OpenSSL 1.1+
- libscrypt 1.8+ (older may work)
- py-scrypt 0.6+ (pip install scrypt)
- libsodium 1.0+

Usage

You can install the most recent release from PyPi using:

pip install pylibscrypt

You most likely want to create MCF hashes and store them somewhere, then check user-entered passwords against those hashes. For that you only need to use two functions from the API:

from pylibscrypt import scrypt_mcf, scrypt_mcf_check
# Generate an MCF hash with random salt
mcf = scrypt_mcf('Hello World')
# Test it
print(scrypt_mcf_check(mcf, 'Hello World'))   # prints True
print(scrypt_mcf_check(mcf, 'HelloPyWorld'))  # prints False

For full API, you can try help(pylibscrypt) from python after importing.

It is highly recommended that you use a random salt, i.e. don't pass one.

Versioning

The package has a version number that can be read from python like so:

print(pylibscrypt.__version__)

The version number is of the form X.Y.Z, following Semantic Versioning6. Unreleased versions include a -git version specifier, e.g. 2.0.0-git < 2.0.0. Releases are tagged vX.Y.Z and release branches bX.Y.x when they differ from master.

Development

Development happens on GitHub7. If you find a bug, please open an issue there.

Running pylibscrypt.tests will test all implementations with some quick tests. Running any implementation directly (e.g. pylibscrypt.pylibsodium) will also compare to scrypt test vectors from the paper but this is slow for the pure Python version (pypyscrypt) unless running with pypy.

You can test more comprehensively using the docker test environment. Either build and run using make docker-run or pull the jvarho/pylibscrypt image and run using docker run -v ${PWD}:/app jvarho/pylibscrypt.

Pull requests should be automatically tested and will not be merged if broken.

pylibscrypt's People

Contributors

Stargazers

Watchers

Forkers

wizardofozzie gvcgael gurnec

pylibscrypt's Issues

from foo import *

First i found a start import in example.py... ok is't only the example...

Then i looked a little around and found many usage of star imports.

IMHO it's really bad practice.

Error when libsodium misses a dependency

If libsodium.dll misses a dependency (like visual C++ redistributables 2013), the lib throws an exception and doesnt use the python implementaion.

https://github.com/jvarho/pylibscrypt/blob/master/pylibscrypt/libsodium_load.py

    sys_sodium = ctypes.util.find_library('sodium')
    if sys_sodium is None:
        sys_sodium = ctypes.util.find_library('libsodium')

    if sys_sodium:
        return ctypes.CDLL(sys_sodium)

If libsodium is present but misses a dependency, the find_library returns a correct path, but ctypes.CDLL throws an Exception.

Make $7$ standard MCF the default

Switch to using the semi-standard $7$ prefix by default.

Incompatible change, so should wait for 2.0.
Affects only scrypt_mcf.

Add CI tests for hashlib.scrypt version

This requires a Travis environment with Python 3.6 build for OpenSSL 1.1.

Need to build both from source?

Readme shows string input not binary.

mcf = scrypt_mcf('Hello World')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.6/site-packages/pylibscrypt/hashlibscrypt.py", line 72, in scrypt_mcf
    return mcf_mod.scrypt_mcf(scrypt, password, salt, N, r, p, prefix)
  File "/usr/lib/python3.6/site-packages/pylibscrypt/mcf.py", line 216, in scrypt_mcf
    if b'\0' in password:
TypeError: 'in <string>' requires string as left operand, not bytes

Change Readme to show:

mcf = scrypt_mcf(b'Hello World')

What's about using travis-ci.org and Co. ?

IMHO it's needful to use https://travis-ci.org and https://coveralls.io and maybe https://landscape.io

MCF $7$ prefix support compatible with libsodium

As per
https://gitorious.org/scrypt/scrypt-unix-crypt/source/b0f9c2ad52775df4fd95ae33ba4cd5f6d113a5fb:unix-scrypt.txt

Read support in branch mcf-7
Write support TODO
Switching the default would require bumping version to 2.0

Loading libsodium on windows should be handled better

Hello

Thanks a lot for this amazing library. I was looking for a scrypt library for python, and most of libraries cannot be integrated in cxfreeze or were handled very badly on windows systems.

Your library works on windows, but it could be done better. To have pylibscrypt load libsodium succefully, I had to copy the DLL to System32 and rename it to "sodium.dll".

The library "libnacl" shows a better way to load the library in a portable way :
https://github.com/saltstack/libnacl/blob/master/libnacl/__init__.py

Thanks in advance,

Inso

Drop python 3.3 support

Dropping support for Python 3.3 allows getting rid of pbkdf2.py and a bunch of tests.

Deprecate as soon as it goes out of support (planned 2017-09-29) and drop in the next release after one with deprecation warnings.

Python 3

The module doesn't actually work in python3 and doesn't seem to have ever worked.

Stupid relative imports probably won't allow both python3 support and using the files as non-package modules at the same time.

Add direct unicode support?

It is a bit inconvenient having to encode passwords before passing them to the MCF functions. Perhaps it would be better to handle conversions from u"strings" automatically. Need to consider potential for regressions when moving between python versions, though.

Drop libsodium_salsa

Only useful with libsodium < 0.5

libsodium pwhash API change

Hi,

Looks like you are the only one to use this API, and sodium 0.5.0 hasn't been released yet, so hope it's okay.

Just a heads up about this change: jedisct1/libsodium@30c1e13

memlimit and opslimit have been switched to match the order of the proposed API of the Password Hashing Competition.

No other API changes are going to happen before the release.

Use hashlib.scrypt on Python 3.6 + OpenSSL 1.1 (i.e. when available)

Cf. https://docs.python.org/3.6/library/hashlib.html#hashlib.scrypt

String TypeError in version 1.6.1

Using Python 3.6.1 (64-bit) on Windows, and pylibscrypt 1.6.1:

(venv) C:\xyz>python
Python 3.6.1 (v3.6.1:69c0db5, Mar 21 2017, 18:41:36) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from pylibscrypt import scrypt_mcf, scrypt_mcf_check
>>> mcf = scrypt_mcf('Hello World')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\xyz\venv\lib\site-packages\pylibscrypt\pypyscrypt_inline.py", line 228, in scrypt_mcf
    return mcf_mod.scrypt_mcf(scrypt, password, salt, N, r, p, prefix)
  File "C:\xyz\venv\lib\site-packages\pylibscrypt\mcf.py", line 216, in scrypt_mcf
    if b'\0' in password:
TypeError: 'in <string>' requires string as left operand, not bytes

libsodium 0.6 updates

scrypt functions renamed from xsalsa to salsa
new _ll function for calling the low level scrypt

In the algorithm, 2**15 gives a valueerror

But 2**14 still works.

This is only in a recent version I think.

Note that 2**20 is still a possible value in the paper.

Drop constant salt support from scrypt_mcf

This would make all password storage to use random salts which is the right thing to do.

Incompatible change should wait for 2.0.
OTOH, the salt parameter could simply be ignored...