passlib issueshttps://foss.heptapod.net/python-libs/passlib/-/issues2020-04-21T18:16:59Zhttps://foss.heptapod.net/python-libs/passlib/-/issues/24support SASLprep in CryptContext2020-04-21T18:16:59ZBitbucket Importersupport SASLprep in CryptContext*Created originally on Bitbucket by Anonymous*
===== //(Imported from Google Code)//
Passlib currently takes in whatever unicode sequence is offered, and hashes it. However, there unicode normalization issues, non-printing code point...*Created originally on Bitbucket by Anonymous*
===== //(Imported from Google Code)//
Passlib currently takes in whatever unicode sequence is offered, and hashes it. However, there unicode normalization issues, non-printing code points (eg SHY) that should be discarded, and many other things which might cause problems reproducing the correct hash from differing user input.
SASL has already addressed this problem via the SASL stringprep profile - [[https://tools.ietf.org/html/rfc4013|https://tools.ietf.org/html/rfc4013]] - this provides a well-thought out unicode normalization policy to prepare passwords for hashing.
It would be good to integrate this into passlib, but it would have to be done in a way that wouldn't impact existing hashes and deployments, which may be relying on other policies. One possible way would be to added a 'stringprep' option to CryptContext, and let it take care of preparing passwords before hashing them.
Wishlisthttps://foss.heptapod.net/python-libs/passlib/-/issues/33Command-Line tool2020-05-03T13:18:36ZBitbucket ImporterCommand-Line tool*Created originally on Bitbucket by Anonymous*
===== //(Imported from Google Code)//
The cmdline-dev branch ( [[https://code.google.com/p/passlib/source/list?name=cmdline-dev|https://code.google.com/p/passlib/source/list?name=cmdline...*Created originally on Bitbucket by Anonymous*
===== //(Imported from Google Code)//
The cmdline-dev branch ( [[https://code.google.com/p/passlib/source/list?name=cmdline-dev|https://code.google.com/p/passlib/source/list?name=cmdline-dev]] ) contains a work-in-progress command line tool for manipulating password hashes.
It can be invoked via "python -m passlib " under py27 and up, or "python -m passlib.__main__ " for py25/26.
It currently contains tools for benchmarking the hashes, encrypting hashes, verifying hashes, and a nice little heuristic for identifying unknown hashes.
Basic functionality is there, but it's rough around the edges. Once completed, if it's useful enough, may merge it into default in time for the 1.7 or 1.8 release.
Wishlisthttps://foss.heptapod.net/python-libs/passlib/-/issues/34IronPython support2020-04-21T18:17:06ZBitbucket ImporterIronPython support*Created originally on Bitbucket by Anonymous*
#### *(Imported from Google Code)*
It would be nice to add IronPython to the list of VMs which passlib supports.
However, IronPython's unicode/bytes handling is a little funky: it's n...*Created originally on Bitbucket by Anonymous*
#### *(Imported from Google Code)*
It would be nice to add IronPython to the list of VMs which passlib supports.
However, IronPython's unicode/bytes handling is a little funky: it's native string type is unicode (ala Python 3), but encoding or decoding a unicode string results in another unicode string:
>>> u'\xA3'.encode('utf-8')
u'\xC2\xA3'
>>> u'\xC2\xA3'.decode("utf-8")
u'\xA3'
Because of this, the following snippet is *not* idempotent under IronPython (unlike every other python 2 & 3 vm):
if not isinstance(source, bytes):
source = source.encode("utf-8")
This is particularly a problem for passlib, since passwords have to be encoded *just so* for the hashes to verify correctly. One alternative might be to research ways to make passlib less strict, but I'm not sure how I feel about that in theory, much less whether it would be sufficient to solve the problem.
So putting the ironpython-support-dev branch on the back burner for now.
Wishlisthttps://foss.heptapod.net/python-libs/passlib/-/issues/37Improve programattic access to hashes2020-04-21T18:17:08ZBitbucket ImporterImprove programattic access to hashes*Created originally on Bitbucket by Anonymous*
#### (Imported from Google Code) ####
Various applications which need to dynamically look up hashes, and have taken various routes - trapping calls to {{{getattr(passlib.hash, name)}}}, ...*Created originally on Bitbucket by Anonymous*
#### (Imported from Google Code) ####
Various applications which need to dynamically look up hashes, and have taken various routes - trapping calls to {{{getattr(passlib.hash, name)}}}, access through the clunkily-named passlib.registry methods, etc.
For 1.7, would like to clean this up. Current ideas...
1. expose schemes() and handler() methods similar to CryptContext, placed in the passlib.hash module. This is where people would expect, but need to be sure it won't confusingly pollute the namespace.
2. expose similar methods to (1), but put them in passlib.registry. Don't like having an extra module if it's not needed, but this might be cleaner.
3. expose a "master" CryptContext instance which supports all hashes. would have to work out lazy-loading issues.
Additionally, this probably needs some custom functions such as fuzzy_identify() from the cmdline-dev branch, etc.
Need to study current uses of passlib some more.
1.8https://foss.heptapod.net/python-libs/passlib/-/issues/38Support for a "pepper"2020-10-09T04:01:39ZBitbucket ImporterSupport for a "pepper"*Created originally on Bitbucket by Anonymous*
## (Imported from Google Code) ##
Some password hashing systems make use of a so-called "pepper". Like a salt, but there is a single one, stored externally from the password database, an...*Created originally on Bitbucket by Anonymous*
## (Imported from Google Code) ##
Some password hashing systems make use of a so-called "pepper". Like a salt, but there is a single one, stored externally from the password database, and hopefully in a manner which is as difficult for an attacker to access as possible.
Typical scheme seems to be to create a wrapper hash format, which calculated `orighash(hmac(password, pepper), salt)`.
Some systems also store multiple peppers, allowing migration if one is considered compromised.
Will have to study this some more, not currently sure if this provides any useful security protections (e.g. in the case of a database compromise). Also need to decide where to insert this - as an extension, as a feature of CryptContext, or as a separate hash algorithm?
Wishlisthttps://foss.heptapod.net/python-libs/passlib/-/issues/60custom_app_context.verify performance decreased largely after upgrading to 1.6.52020-04-21T18:17:27ZBitbucket Importercustom_app_context.verify performance decreased largely after upgrading to 1.6.5*Created originally on Bitbucket by Anonymous*
Here is the code I used for testing:
```
#!python
from passlib.apps import custom_app_context as pwd_context
hash = pwd_context.encrypt("somepass")
for _ in range(1,100):
...*Created originally on Bitbucket by Anonymous*
Here is the code I used for testing:
```
#!python
from passlib.apps import custom_app_context as pwd_context
hash = pwd_context.encrypt("somepass")
for _ in range(1,100):
ok = pwd_context.verify("somepass", hash)
```
* Version 1.6.2: 31 seconds
* Version 1.6.5: 182 seconds
Also the 100 loop encrypt slowed down from 28 seconds to 182 seconds.1.8https://foss.heptapod.net/python-libs/passlib/-/issues/65Cmdline tool for generating system-specific custom context configs2020-04-21T18:17:30ZBitbucket ImporterCmdline tool for generating system-specific custom context configs*Created originally on Bitbucket by Anonymous*
As evidenced by cases such as issue #60, `passlib.apps.custom_app_context` may not be the right approach, as it's trying to be a 'one size fits all' solution in a world where there a wide v...*Created originally on Bitbucket by Anonymous*
As evidenced by cases such as issue #60, `passlib.apps.custom_app_context` may not be the right approach, as it's trying to be a 'one size fits all' solution in a world where there a wide variety of CPU speeds and performance characteristics.
Adding some code to custom_app_context which performed system-depending timing tests after each load would introduce unacceptable delays in application startup; and trying to cache this information in the filesystem would add needless api headache for developers wishing to get up and running quickly.
The only remaining solution seems to be to replace/supplement `custom_app_context` with a command line tool that performs timing tests (using the code from `$SRC/choose_rounds.py`), and outputs a CryptContext configuration string for developers to use, tuned specifically to their system.
To make sure they regenerate this periodically, would need to give the string an "expiration" date, which could be done by adding a CryptContext configuration option to issue a PasslibSecurityWarning once the configuration was older than a certain date.Wishlisthttps://foss.heptapod.net/python-libs/passlib/-/issues/72Simple hashing functions should be supported2020-04-21T18:17:35ZBitbucket ImporterSimple hashing functions should be supported*Created originally on Bitbucket by Anonymous*
I'd like to see support for simple hashing protocols like MD5, SHA1, SHA-256, etc... The purpose is to store hashes of files using the uniform Modular Crypt Format and passlib.
Is this s...*Created originally on Bitbucket by Anonymous*
I'd like to see support for simple hashing protocols like MD5, SHA1, SHA-256, etc... The purpose is to store hashes of files using the uniform Modular Crypt Format and passlib.
Is this something you would like to see making it's way to passlib?1.8https://foss.heptapod.net/python-libs/passlib/-/issues/74Allow configuring custom contexts by extending CryptContext2020-04-21T18:17:36ZBitbucket ImporterAllow configuring custom contexts by extending CryptContext*Created originally on Bitbucket by Anonymous*
Besides creating custom CryptContext instances by passing the context configuration as parameters or loading it from a file:
```
#!python
pwd_context = CryptContext(
schemes=["pbk...*Created originally on Bitbucket by Anonymous*
Besides creating custom CryptContext instances by passing the context configuration as parameters or loading it from a file:
```
#!python
pwd_context = CryptContext(
schemes=["pbkdf2_sha256", "des_crypt" ],
default="pbkdf2_sha256",
all__vary_rounds = 0.1,
pbkdf2_sha256__default_rounds = 8000,
)
myctx3 = CryptContext.from_path("/some/path/on/local/system")
```
It would be nice to allow CryptoContext configuration by overriding its fields like :
```
#!python
class MyCryptContext(CryptContext):
schemes = ["pbkdf2_sha256", "des_crypt"]
default_scheme = "pbkdf2_sha256"
all__vary_rounds = 0.1
pbkdf2_sha256__default_rounds = 8000
```
Or:
```
#!python
class MyCryptContext(CryptContext):
schemes = [
{
'scheme': 'pbkdf2_sha256',
'vary_rounds': 0.1
},
{
'scheme': 'des_crypt',
'default_rounds': 8000,
'vary_rounds': 0.1
}
]
```
And creating the instances from the subclass:
```
#!python
context = MyCryptContext()
```
I think this would be good because:
* Inherently easier to extend
* More "Pythonic" and "OOP"
* It's easier to read (IMHO)
* Doesn't rely on external configuration files and formats
* Allows adding/overriding methods (e.g. loading from and dumping to other formats while keeping full config)1.8https://foss.heptapod.net/python-libs/passlib/-/issues/75Deprecate Modular Crypt format in favor of PHC String Format2020-04-21T18:17:37ZBitbucket ImporterDeprecate Modular Crypt format in favor of PHC String Format*Created originally on Bitbucket by Anonymous*
Now there is a standard.
https://github.com/P-H-C/phc-string-format/blob/master/phc-sf-spec.md
Passlib should adhere to this format.*Created originally on Bitbucket by Anonymous*
Now there is a standard.
https://github.com/P-H-C/phc-string-format/blob/master/phc-sf-spec.md
Passlib should adhere to this format.1.8https://foss.heptapod.net/python-libs/passlib/-/issues/77passlib.totp could offer to_qrcode() helper methods2020-04-21T18:17:38ZBitbucket Importerpasslib.totp could offer to_qrcode() helper methods*Created originally on Bitbucket by Anonymous*
It would be convenient if the OTP classes offered a to_qrcode() method, or at least some guidance about how to take the output from .to_uri(), and generate a qr code.
There's a number of...*Created originally on Bitbucket by Anonymous*
It would be convenient if the OTP classes offered a to_qrcode() method, or at least some guidance about how to take the output from .to_uri(), and generate a qr code.
There's a number of python qrcode libraries, and none immediately stood out as "best". Additionally, many applications may pass uri to web client, and use JS code to render qrcode.
This issue is here to gather discussion about the idea, but probably not going to move on it any time soon.Wishlisthttps://foss.heptapod.net/python-libs/passlib/-/issues/78Using bcrypt and plaintext schemes together may cause a ValueError exception2020-04-21T18:17:39ZBitbucket ImporterUsing bcrypt and plaintext schemes together may cause a ValueError exception*Created originally on Bitbucket by Anonymous*
If the plaintext password happens to start with the prefix that identifies bcrypt, it fails with a ValueError. This snippet reproduces the issue:
```
#!python
from passlib.context ...*Created originally on Bitbucket by Anonymous*
If the plaintext password happens to start with the prefix that identifies bcrypt, it fails with a ValueError. This snippet reproduces the issue:
```
#!python
from passlib.context import CryptContext
passlib_ctx = CryptContext(schemes=[
"bcrypt",
"plaintext",
])
plaintext = 'potato'
hashed = passlib_ctx.encrypt(plaintext)
#problematic_plaintext = '$2a$12$D2ZnWsBaBEJzWxmYK3.A'
#problematic_plaintext = '$2a$12$D7Q0W92sodO2FsqcBYAnnuueFC6bqg1abhMBKfJNGw4l4A0BsR'
#problematic_plaintext = '$2a$12$D'
#problematic_plaintext = '$2a$12'
problematic_plaintext = '$2a$'
assert passlib_ctx.verify(plaintext, plaintext)
assert passlib_ctx.verify(plaintext, hashed)
assert passlib_ctx.verify(problematic_plaintext, problematic_plaintext)
```
I'm not sure how that could be solved. Would catching the ValueError to try the plaintext scheme only be a good idea? This would reduce the possibility of a clash to the case of a plaintext password that is a valid a bcrypt hash. It does not sound like a good idea from a security perspective.
Should I consider this a non-issue if I make sure that all my users are not using a password that clashes with the bcrypt prefix? Or is it something that should be fixed in the library itself?
This probably affects other hash handlers.2.0https://foss.heptapod.net/python-libs/passlib/-/issues/79Convert 'encoding' context keyword to a setting2020-05-11T15:13:52ZBitbucket ImporterConvert 'encoding' context keyword to a setting*Created originally on Bitbucket by Anonymous*
A handful of hashes (such as lmhash) explicitly use a non-unicode encoding by default, but allow a custom one to be passed in as a context keyword to hash() and verify().
Given the adven...*Created originally on Bitbucket by Anonymous*
A handful of hashes (such as lmhash) explicitly use a non-unicode encoding by default, but allow a custom one to be passed in as a context keyword to hash() and verify().
Given the advent of the PasswordHash.using() constructor, this is a much better fit as a *setting*, not a context-specific keyword.
All affected hashes should be converted over. Other hashes might also generally benefit from having an encoding setting that could be passed in via CryptContext.
Marking for 1.8, but this might get bumped forward until 1.9/2.0.1.8https://foss.heptapod.net/python-libs/passlib/-/issues/80Commandline tool to choose correct rounds values2020-04-21T18:17:40ZBitbucket ImporterCommandline tool to choose correct rounds values*Created originally on Bitbucket by Anonymous*
Dovetailing with issue #65, it would be useful to offer a commandline tool (e.g. ``python -m passlib choose-rounds``) which can recommend an appropriate rounds value for a user.
This sh...*Created originally on Bitbucket by Anonymous*
Dovetailing with issue #65, it would be useful to offer a commandline tool (e.g. ``python -m passlib choose-rounds``) which can recommend an appropriate rounds value for a user.
This should be doable by converting & cleaning up the existing ``choose_rounds.py`` script in the repository.Wishlisthttps://foss.heptapod.net/python-libs/passlib/-/issues/81Fork passlib.ext.django out as separate project2020-10-07T14:21:43ZBitbucket ImporterFork passlib.ext.django out as separate project*Created originally on Bitbucket by Anonymous*
The `passlib.ext.django` extension is kinda high maintenance, and with an uncertain number of users. Particularly because unlike a number of bits of Passlib, I don't use this myself.
Th...*Created originally on Bitbucket by Anonymous*
The `passlib.ext.django` extension is kinda high maintenance, and with an uncertain number of users. Particularly because unlike a number of bits of Passlib, I don't use this myself.
The current plan is to split this out as a separate project, removing it from passlib, and make a release concurrent with Passlib 1.8.
Once separate, it should be easier to judge it's utility, whether it continue to be maintained in it's own right. It will also be easier because it's update cycle is closer to that of Django than that of Passlib.1.8https://foss.heptapod.net/python-libs/passlib/-/issues/84Pbkdf2 hashers should accept variable checksum sizes2020-04-21T18:17:42ZBitbucket ImporterPbkdf2 hashers should accept variable checksum sizes*Created originally on Bitbucket by Anonymous*
The pbkdf2_* hashers currently have a fixed checksum size -- that of the underlying digest.
In order to allow them to handle hashes converted from other sources (which e.g. have 16 byte ...*Created originally on Bitbucket by Anonymous*
The pbkdf2_* hashers currently have a fixed checksum size -- that of the underlying digest.
In order to allow them to handle hashes converted from other sources (which e.g. have 16 byte digests, even for sha256), this should be changed so .hash() uses checksum_size as the default, but .verify() adapts the size to whatever the input hash uses.1.8https://foss.heptapod.net/python-libs/passlib/-/issues/87Add support for Cisco PBKDF2 and Scrypt hashes2023-12-01T16:08:59ZBitbucket ImporterAdd support for Cisco PBKDF2 and Scrypt hashes*Created originally on Bitbucket by Anonymous*
Cisco IOS added "type 8" and "type 9" hashes (based pbkdf2-sha256, and scrypt, respectively). Cisco ASA 9.5 added a separate "pbkdf2" hash (based on sha512 based).
Shouldn't be too har...*Created originally on Bitbucket by Anonymous*
Cisco IOS added "type 8" and "type 9" hashes (based pbkdf2-sha256, and scrypt, respectively). Cisco ASA 9.5 added a separate "pbkdf2" hash (based on sha512 based).
Shouldn't be too hard to add support for these. Mainly need to gather together some test vectors, figure out the edge cases (max password size, max parameter sizes, etc). Already have a few accumulated for cisco_asa_pbkdf2.Wishlisthttps://foss.heptapod.net/python-libs/passlib/-/issues/89HtpasswdFile does not like additional fields2020-10-09T14:03:01ZBitbucket ImporterHtpasswdFile does not like additional fields*Created originally on Bitbucket by Anonymous*
Apache and nginx actively support 2 *or more* colon-separated fields in an htpasswd file. But such files break in HtpasswdFile because of [this exception](https://bitbucket.org/ecollins/pa...*Created originally on Bitbucket by Anonymous*
Apache and nginx actively support 2 *or more* colon-separated fields in an htpasswd file. But such files break in HtpasswdFile because of [this exception](https://bitbucket.org/ecollins/passlib/src/849ab1e6b5d4ace4c727a63d4adec928d6d72c13/passlib/apache.py?at=default&fileviewer=file-view-default#apache.py-679). I explained this, and showed evidence from the apache and nginx sorce code, in this bug report on trac: <https://trac.edgewall.org/ticket/12744#comment:2>. (Sorry, nicely formatted links aren't working with that URL for some reason.)
You mentioned [elsewhere](https://bitbucket.org/ecollins/passlib/issues/73/) that there isn't an official spec for the htpasswd format, which makes it hard to know just what makes an acceptable file. But the source code in both projects makes clear that this is not an accident; additional colon-separated fields are allowed. You could allow this by changing
```python
if len(result) != 2:
```
to
```python
if len(result) < 2:
```
I have not looked at the code for digest, but corresponding changes may be needed there, as Ryan J Ollos suggested on trac.1.8https://foss.heptapod.net/python-libs/passlib/-/issues/90postgres_scram hash support2020-08-04T10:31:33ZBitbucket Importerpostgres_scram hash support*Created originally on Bitbucket by Anonymous*
Postgres 10 will be adding a new [scram-sha256](http://paquier.xyz/postgresql-2/postgres-10-scram-authentication/) hash. This should be pretty easy to implement given the existing passlib...*Created originally on Bitbucket by Anonymous*
Postgres 10 will be adding a new [scram-sha256](http://paquier.xyz/postgresql-2/postgres-10-scram-authentication/) hash. This should be pretty easy to implement given the existing passlib.hash.scram library.
Main todos:
* get some test vectors for postgres' scram hash format.
* clean up existing scram hash internals so we can subclass out common bits.
* modify existing scram hash to support "client" vs "server" hashes, which store just the required subkeys.1.8https://foss.heptapod.net/python-libs/passlib/-/issues/94period setting does not seem to work (stuck at default) and is actually twice...2020-04-21T18:17:48ZBitbucket Importerperiod setting does not seem to work (stuck at default) and is actually twice as long as defined*Created originally on Bitbucket by Anonymous*
While trying out different implementations for a TOTP application I stumbled over a weird behaviour: The timing behaviour for the passlib library did not work as expected.
I wrote a short ...*Created originally on Bitbucket by Anonymous*
While trying out different implementations for a TOTP application I stumbled over a weird behaviour: The timing behaviour for the passlib library did not work as expected.
I wrote a short script to directly compare passlib and pyotp.
As you can see in the output below, the token was actually the same (good) and the timing verification was the same for both implementations (5s).
When stepping through the time window in one second intervals, the result was quite different though:
1) The pass lib result indicates that the 5s period was not used, rather the 30s default seems to have been used
2) The passlib implementation uses the period symmetrically around the time reference, in effect doubling the allowed time window
I verified the results with 6 and 8 digits and ran it also on a Linux system with the same results.
(script result)--------------
version data
platform info: Darwin-16.6.0-x86_64-i386-64bit
python info: 3.6.0 (v3.6.0:41df79263a11, Dec 22 2016, 17:23:13)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]
passlib version: 1.7.1
pyotp version: 2.2.6
parameters
Allowed Duration (s): 5
current datetime: 2017-07-20 14:55:51.484219
current datetime in s: 1500555351
key_string: "this is a test"
encoded key_string: b'ORUGS4ZANFZSAYJAORSXG5A='
passlib setup
full token: <TotpToken token='977416' expire_time=1500555355>
passlib token-base: <passlib.totp.TOTP object at 0x103592320>
verify passlib token-base duration: 5
passlib token: 977416
pyotp setup
pyotp token-base: <pyotp.totp.TOTP object at 0x10358acc0>
verify pyotp token-base duration: 5
pyotp token: 977416
passlib switched to true at (unix epoch, offset): 1500555320,-31
pyotp switched to true at (unix epoch, offset): 1500555350,-1
pyotp switched to true at (unix epoch, offset): 1500555355,4
passlib switched to false after true at (unix epoch, offset): 1500555385,341.8