Secret phrase may not contain email address

[45678]

Recently introduced in miniLock master. I have reservations about the implementation...

[Fastidious]

Could you elaborate? Curious.

[45678]

It is funny you noticed this because it was meant as a note to myself.

Currently a miniLock secret phrase may not include your email address. I think that is reasonable but it couples the validation of the secret phrase to the email address input. So, to validate the secret phrase you need to check the email input also which I think is needlessly complicated. To make it less complicated I think the secret phrase should not be permitted to include ANY email address. That way it can be validated independently and the expectations become really clear for operators.

Additionally, on more than one occasion I have pasted my miniLock ID into the secret phrase field by mistake. Since a miniLock ID has a lot of entropy it is usually acceptable as a secret phrase. And since the input of a secret phrase field is usually hidden (••••) I don’t know that I’ve made a mistake. So I suggest that the secret phrase should not be permitted to include ANY miniLock ID.

I am still working up the courage to propose this at miniLock HQ. Most of the people there seem to really hate me :(

[45678]

By the way, thank you for the support regarding saving the time of encryption in the file format.

[Fastidious]

I agree with both, not to allow any email address nor a miniLock ID. On my tests I have used my email and ID twice as a password.

I do not think they hate you, you have contributed quite a bit to miniLock, very good contributions!

You are very welcome.

[hdf]

I support the idea, that the password should not be allowed to contain miniLockID's, nor email addresses, in addition I would like it if the library was a bit more general, and not require an email address, nor force the signing of all encrypted data. Would be nice if the library could be used in a Perfect Forward Secrecy kind of setting. What do you think?

[grempe]

If you use zxcvbn for passphrase entropy check you can have it add the contents of another field into its dictionary (such as the email field) and it will reduce the calculated entropy of a passphrase if it contains the string from the other field.

zxcvbn(password, user_inputs)

The optional user_inputs argument is an array of strings that zxcvbn will add to its
internal dictionary. This can be whatever list of strings you like, but it’s meant for
user inputs from other fields of the form, like name and email. That way a password
that includes the user’s personal info can be heavily penalized. This list is also good
for site-specific vocabulary. For example, ours includes dropbox.

https://blogs.dropbox.com/tech/2012/04/zxcvbn-realistic-password-strength-estimation/