search

45678 / miniLockLib

Do miniLock encryption operations on a web page of your own.
https://45678.github.io/miniLockLib/
The Unlicense
11 stars 2 forks source link

Secret phrase may not contain email address #5

Open 45678 opened 10 years ago

45678 commented 10 years ago

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

Fastidious commented 10 years ago

Could you elaborate? Curious.

45678 commented 10 years ago

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 commented 10 years ago

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

Fastidious commented 10 years ago

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 commented 9 years ago

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 commented 8 years ago

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/