jaraco / jaraco/keyring

Support longer passwords in Windows

Open
#540 7 comments 0 reactions 0 assignees View on GitHub
enhancement help wanted Windows
Dominant language
Python
Stars
1.5k
Forks
196
PR merge metrics
No merged PRs in 30d

Description

@jaraco I know this issue is closed, but the Windows limit is getting in our way, too, and I have a possible idea for how to fix it.

Here's the version of Windows I'm on

```
Edition Windows 10 Pro
Version 21H1
Installed on ‎5/‎1/‎2021
OS build 19043.1320
```

The limit documented by @cvubrugier is the same limit I am experiencing: 1280 max for the password.

Yet some packages use `keyring` to store tokens (JWT) in `keyring`, and these tokens can easily exceed 1280 bytes.

So my idea is to edit `https://github.com/jaraco/keyring/blob/main/keyring/backends/Windows.py`, in particular `_set_password` and `_get_password`, notice the "too big" password, and split it up into as many pieces as necessary, giving each one a unique (and numbered) `TargetName`.

Since `_set_password` and `_get_password` are the callers of `win32.CredWrite` and `win32.CredRead`, I can transparently split the password up in `_set_password` and then transparently re-join it up in `_get_password` and no other code will be the wiser for it.

I've prototyped this and it works.

Is this a PR you would potentially welcome (or, minimally, indulge?)

_Originally posted by @jrobbins-LiveData in https://github.com/jaraco/keyring/issues/355#issuecomment-963661996_

Contributor guide

No contributing guide indexed for this repository

Research direction

Start in keyring/backends/Windows.py and read _set_password and _get_password, including their calls to win32.CredWrite and win32.CredRead. Review how oversized passwords are currently handled, then define a compatible way to split and reassemble values across numbered TargetName entries. Done means passwords beyond the Windows limit can be stored and retrieved transparently.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
backend
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.