Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security considerations (a.k.a maybe a note in the README wouldn't hurt) #6

Open
gonzalo-bulnes opened this issue Oct 13, 2018 · 1 comment
Labels
up for discussion Everything is up for discusson, but this topic particularly so!

Comments

@gonzalo-bulnes
Copy link
Owner

gonzalo-bulnes commented Oct 13, 2018

Dice is about passwords (passphrases).

What kind of security implications does that have?
What should we take into consideration when writing it?
What should we consider when using it?

I started thinking more seriously about this when considering what problem would be addressed by making sure that:

[Users] can take the list that ships with the application and verify it is the same as the one provided by EFF themselves. (source)

And after some relfection I think that dice does not deserve the security scrutiny that one could think of at first, or rather, that probably:

Nobody should use dice unless they understand its code.

If you find that a bit disapoining, so do I! But before getting to why I think that, I believe the implications are that:

  • making the code as easy to review as possible should be a priority
  • there is likely value in also keeping the code simple, so that proficiency with Rust is not critical to review it (goal: making the code accessible to a larger user base)
  • ensuring that once someone has reviewed the code, they can be reasonably sure about what's in the binary (that is less obvious than it might seem) would also help making distribution easier (compiling from the sources is never that straightforward)
@gonzalo-bulnes gonzalo-bulnes added the up for discussion Everything is up for discusson, but this topic particularly so! label Oct 13, 2018
@gonzalo-bulnes
Copy link
Owner Author

Dice makes the looking up words in a wordlist easier for the purpose of generating passphrases.

What makes one wordlist different from another?

This matters when the wordlist in use is not the one you think (whether it is a mistake, an intentional alteration, or the code is manipulating the words in a mistaken or mischievious way).

What characterizes a wordlist is:

  • memorability: how easy it is for you to remember the passphrases generated using that wordlist
  • average entropy per word (a.k.a "randomness"): how random are the the passphrases generated using that wordlist. The higher the average entropy per word the shorter you can make your passphrases for a given (average) security level. (That in turn tends to make them easier to remember.)

Risks: using a program that doesn't return you accurately the words from your chose wordlist may result in your passwords being (in average) weaker than you expect.

Note that there is no need for a tool to lookup the words in the wordlist! You could print the list and read them without any computer at all.

That is why, personally, I consider this risk is not worth it. It is a personal choice, based on the fact that I only use this method to generate the few passphrases that I need to remember or type regularly (e.g. WiFi passphrase). Dice saves me time, but I wouldn't use it if I couldn't review it to make sure it works as I expect. And that is what makes me state that, in my opinion:

Nobody should use dice unless they understand its code.

Seriously I don't think it is worth the risk. 🙂
(That also probably explains why the EFF published wordlists without any such tool to look them up.)

Does that mean nothing matters?

Absolutely not! I'm quite happy I wrote Dice, I've used it and it's made my day once. But it means that making Dice easy to review is the only way I can ethically recommend it to people. It also means that this disclaimer should probably be in the README. 😋

Making code easy to review, is not a bad goal when learning a language. And as it is now Dice can be made a lot clearer.

Also finding ways to distribute a tiny tool that preserve the level of trust that the code review established is also worth figuring out I think. I haven't done it before (I don't sign the releases of my other packages for example), and I am keen on seeing if it would bring any value in this case.

That's for my security thoughts!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
up for discussion Everything is up for discusson, but this topic particularly so!
Projects
None yet
Development

No branches or pull requests

1 participant