bip85 passwords

[scgbckbone]

BIP-85 Passwords

Application number 707764' was chosen as follows:
b"pwd" --> [112, 119, 100] ---to hex--> 707764 + make it hardened --> 707764'

Rationale

Having ability to generate countless number of strong passwords from one seed (one seed to rule them all). Main intention is to generate very strong passwords for sensitive applications like encrypting of ssh keys, master password for password managers etc. Passwords are constrained by length. Min. 20 character and max. 86 character. Generated passwords have at least 120 and maximum of 516 bits of entropy. This is provably overkill for applications like Gmail or twitter but is not the intended use case anyway.

Passwords are generated by encoding whole 64 bytes of generated entropy and removing any spaces or new lines inserted by Base64 encoding process. Slice base64 result string
on index 0 to pwd_len. This slice is the resulting password. As pwd_len is limited to 86, passwords will not contain padding.

Base64 is a great and well known candidate for password use case as it contains both lower/upper case characters, numbers and special characters + and /.

Constraints

• pwd_length min. 20 max. 86

Changes:

• fix typo in XPRV
• fix formatting in other implementations
• new application = passwords

Implementations:

• already implemented in btc-hd-wallet
• opened PR in reference implementation
• opened PR to Coldcard firmware (merged in Coldcard/firmware@26986cf)

[junderw]

This needs to account for different password requirements.

[scgbckbone]

hi, can you elaborate?

My thinking was a-zA-Z0-9+/= should make most of the "password strength" calculators happy. Also you can make sure you will have at least one special character in the password if you choose num_bytes so that password will contain padding (=)

[junderw]

1. I have to make a password for my bank
2. It requires a password of a-zA-Z no numbers, length of 8-12 characters

Of course, I could write down a txt file saying "I used BIP85, then I used this index, then I removed all non alphabet characters because the bank refused the other ones" and keep it with my seed...

But at that point, this is less useful than just writing down a randomly generated password.

[junderw]

So, ie. instead of num_bytes, maybe use multiple variables

1. length (as is, the length of the output password)
2. character_types (this should be a bit field where each of the 31 bits available for the derivation path layer represents a type of character (lowercase a-z, uppercase A-Z, numbers, then you have 28 bits to divide into symbols somehow, or just have one bit mean a specific set of symbols)
3. password_domain (perhaps make this the first 31 bits of the SHA256 of the TLD domain name ie. facebook.com and not https://login.facebook.com/login.asp?r=dsdfhk)

etc etc etc

[scgbckbone]

1. I have to make a password for my bank

   2. It requires a password of a-zA-Z no numbers, length of 8-12 characters

Of course, I could write down a txt file saying "I used BIP85, then I used this index, then I removed all non alphabet characters because the bank refused the other ones" and keep it with my seed...

But at that point, this is less useful than just writing down a randomly generated password.

I would like to keep length requirements same as for hex 16-64 as I want this to generate strong passwords - on par with bitcoin security (min. cca 128bits) --> now I'm not sure if it is good idea to start generating passwords as your bank requires, between 40 -65bits of entropy, which seems to be low (on top for financial applications). Yet I know that there are lots of apps with "strange" password requirements out there. Thoughts ?

[scgbckbone]

So, ie. instead of num_bytes, maybe use multiple variables

1. `length` (as is, the length of the output password)

2. `character_types` (this should be a bit field where each of the 31 bits available for the derivation path layer represents a type of character (lowercase a-z, uppercase A-Z, numbers, then you have 28 bits to divide into symbols somehow, or just have one bit mean a specific set of symbols)

3. `password_domain` (perhaps make this the first 31 bits of the SHA256 of the TLD domain name ie. `facebook.com` and not `https://login.facebook.com/login.asp?r=dsdfhk`)

etc etc etc

1. num_bytes was chosen with regards to base64 encoding where you can manage number of padding in your password, you cannot do this with password_length as you would need another variable specifying padding (in base64 one pwd length maps to three diferrent passowrds, you can check the whole table here)
2. wouldn't this require us to write our own character encoding schemes?
3. not sure what you mean here - ? - but if you're talking about application number --> I have chosen it as follows --> b"pwd" --> [112, 119, 100] ---to hex--> 707764

[scgbckbone]

REMAKE:

• num_bytes changed to pwd_len
• base64 encode whole 64 bytes of generated entropy
• slice out password length base64_encoded_entropy[0:pwd_len]
• no more padding (as max pwd length is 86)

[doc-hex]

comment about Banks and other junk websites with silly password requirements:

• it's impossible to satisfy them all
• there is no science to their requirements anyway
• we are not a password manager, and you need the "username" data to go with.
• but maybe this BIP-85 password is the ultimate password that protects your password manager itself.

[luke-jr]

@ethankosakovsky

[scgbckbone]

@ethankosakovsky

above account is imo gone (rumor goes that he/she created it just for bip85 and no longer watch it or respond)

[luke-jr]

Nevertheless, this cannot be merged without an ACK from that human.

[nvk]

ACK

[scgbckbone]

Nevertheless, this cannot be merged without an ACK from that human.

Do we have any contingency plan in case "that human" is gone? (which seems to be the case)

[junderw]

Do we have any contingency plan in case "that human" is gone? (which seems to be the case)

Make a new BIP. Many BIPs reference other BIPs.

[luke-jr]

From BIP 2:

It occasionally becomes necessary to transfer ownership of BIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred BIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the BIP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the BIP. We try to build consensus around a BIP, but if that's not possible, you can always submit a competing BIP.

If you are interested in assuming ownership of a BIP, send a message asking to take over, addressed to both the original author and the BIP editors. If the original author doesn't respond to email in a timely manner, the BIP editors will make a unilateral decision (it's not like such decisions can't be reversed :).

[scgbckbone]

sent email with request to transfer ownership to bip editors and @ethankosakovsky

[ethankosakovsky]

I would like to keep length requirements same as for hex 16-64 as I want this to generate strong passwords - on par with bitcoin security (min. cca 128bits) --> now I'm not sure if it is good idea to start generating passwords as your bank requires, between 40 -65bits of entropy, which seems to be low (on top for financial applications). Yet I know that there are lots of apps with "strange" password requirements out there. Thoughts ?

I love the concept in general but the problem is there are a lot of strange password policies being enforced. Many don't calculate entropy correctly - for example, a long password a-zA-Z0-9 being considered unacceptable regardless of the because of no symbols. I have seen website enforcing upper, lower, numerals, and symbols and must be a specific length. So even with a 25 character password of a-zA-Z0-9.

Would I be correct in assuming there no guarantee a password generated under this proposed method would be acceptable by all websites? How do you handle cases where password change policy is in effect forcing you to change your password every 90 days or whatever. Or if for any reason (like a breach) the website forces a password reset on everyone.

I think it's a pity we're only generating passwords according to the base64 alphabet. It would seem more appropriate to use hex 0x20 (or maybe 0x21) until 0x7e which is the full range of ASCII roman letters, numerals and basic symbols. It would achieve a lot more entropy for shorter passwords as well.

On a side note, I would like to comment that I think the speed at which you're proposing and implementing does not really allow for community input. From opening the PR to already having it implemented in 3rd party systems was just a matter of days. For the record, I felt extremely pressured in the beginning of BIP85 proposal. While it was wonderful to have the enthusiasm for the idea, some aspects were rushed in trying to avoid a split proposal/implementation (i.e. implemented differently in Coldcard vs the BIP). It really does take time to consider the cases, and for community input. I think there needs to be more evangelizing of the proposal to garner feedback - surely there are things that others might consider that we didn't. While BIP85 deliberated avoided inventing new cryptography by seeking to repurpose existing proven technology, the implementation and usecases could have done with a bit more polishing.

Back to the proposal, there are other problems, in that some sites enforce restrictions on password length. This proposal really falls a bit short on these numerous cases. I also wonder if there shouldn't really be some form of salt involved, using the domain name as a DN of sorts. This might allow iterating when password changes are forced or required due to a breach on the provider's side.

[scgbckbone]

@ethankosakovsky welcome back! (sorry for pronouncing you gone)
@luke-jr consider my email to change ownership of the BIP void.

"lot of strange password policies being enforced" --> true and we will never make them all happy. We shouldn't some of them are pretty dumb. My bank for instance does not allow passwords longer than 20 characters (I wrote to them on multiple occasion but they just do not care)

"Would I be correct in assuming there no guarantee a password generated under this proposed method would be acceptable by all websites?" --> same as above, we will never make them all happy

"How do you handle cases where password change policy is in effect forcing you to change your password every 90 days or whatever. Or if for any reason (like a breach) the website forces a password reset on everyone." --> no strategy for that, I would just bump derivation index. Open to this "I also wonder if there shouldn't really be some form of salt involved, using the domain name as a DN of sorts. This might allow iterating when password changes are forced or required due to a breach on the provider's side." but think it really complicates the concept

"I think it's a pity we're only generating passwords according to the base64 alphabet. It would seem more appropriate to use hex 0x20 (or maybe 0x21) until 0x7e which is the full range of ASCII roman letters, numerals and basic symbols. It would achieve a lot more entropy for shorter passwords as well." --> open to this, bas64 for chosen for its availability and I know that I want to generate long passwords so character set did not matter that much

If we find better way of doing this - I will gladly submit PR to Coldcard, as feature there is very new and not heavily used.

[ethankosakovsky]

base85 would encode almost all the printable symbols and it's already part of base64 library in Python for example.

base64.b85encode()
base64.b85decode()

0123456789
ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz
!#$%&()*+-;<=>?@^_`{|}~

[ethankosakovsky]

@scgbckbone Well I would suggest either adjusting this to use Base85, or if it's already deployed too widely, add a second program option with Base85 for the encoding.

@luke-jr ACK

[scgbckbone]

I know above is not ideal (2 application numbers instead of just one and add another derivation path component {64,85}) but I do not want to "fork off" anyone already using this...

[ethankosakovsky]

ACK

[dr-orlovsky]

My concern about this proposal is the fact that BIP85 master seed is a highly-valuable information which has to be kept in the most secure way (since it assumed to derive all the rest seeds eveywhere). On the other hand, creating new passwords is a daily thing, and since it uses private key entropy it would require to keep the whole BIP85 seed as a hot wallet!

So my proposal is to have a BP85 path to derive another "BIPXXX" seed, which must not be used for anything else than passwords derivation (according to the proposed specification in this PR) - and put it as an independent BIP. In this case we can easily keep the specific xpriv as a hot wallet, since it would not compromise anything else than a set of password.

[zhekazuev]

Hello everyone,

FYI, there is a project that works the way @scgbckbone described I think: https://github.com/nelkor/passcryptum .
Algorithm: https://github.com/nelkor/passcryptum/blob/main/docs/en/password-generation-algorithm.md

Just as a reference.