Hello. I'm interested in using this crate to manage my passwords, but I noticed that it requires the master password to be an argument in the initial command. As a result, it is fully visible and is stored in the command line history. I would like it to be able to read the master password from standard input without echoing the characters, like most command-line utilities that take passwords do.

Based on a cursory reading of the source code, it shouldn't be too hard to add a case for when the password isn't one of the arguments, and I found the rpassword crate, which is designed for this kind of input. I'll see if it's as simple as I think. If it is, you can expect a pull request in the next few days.

I'd like to use lesspass on an embedded device, that means making it no_std and preferably also avoiding allocations and dependencies using allocations. I have some patches towards this, but wanted to discuss #4 and the overall goal first.

If the counter is greater than 9, the generated passwords are different from those generated with official implementation.

For example, using as masterpassword "alice" and following config:

{
  "login": "[email protected]",
  "site": "counter.com",
  "uppercase": true,
  "lowercase": true,
  "numbers": true,
  "symbols": true,
  "length": 35,
  "counter": 10
}

Official implementation returns: Ud|}&F#JP=tgW^)/(kpbZNg$~u$D6y1o9'l
This implementation returns: ?AHLJt0h\x3$]6Ujrd]SrgQpCE82~o^_;9}

If counter is 9 or lower seems work fine.

Other problem is that the counter can be a number bigger than 99, in official implementation the biggest number that you can use is 10000000000000000. I think that is an enormous number, but IMHO you should use u16 (u8 is too low) to set max counter value to 65535.

The password length in official implementation is 5 as lowest value and 35 as highest value. With this API you can't use 5 as lowest value and highest value is 64, with lengths higher than 35 you can obtain upredictable results and after character 44 you only have garbage.

% ./lesspass --sha512 -l 64 counter.com [email protected] alice
!0AaI*'x)8\`7`A8>}uembMqPR.GiJ~=5r;pL:?DH.1aaaaaaaaaaaaaaaaaaaaa
% ./lesspass -l 64 counter.com [email protected] alice 
!0AaS{[YK?p(t(T+_x{sG1Fje`dd%:ie2),yD>"mY29aaaaaaaaaaaaaaaaaaaaa

I don't know how to program and compile,
can you provide compiled binaries?

I'm using this crate as a library for a personal tool, and came across this issue when trying to use environment variables as input without validating them to be UTF-8. Now that I'm thinking about it I could just error out if they're not valid UTF-8, but I would still like to be able to do these kinds of things and it is a needless restriction of the API. I'm curious to know your thoughts and/or reasoning behind it.

I see the following problems with the API:

• It is a bit of a leaky abstraction. Note, for example, how we couldn't change the crypto library without changing the API. Similarly, since almost all functions are public, it is impossible to change the structure of the implementation without breaking the API.
• The API is needlessly complex. It exposes intermediate steps of the algorithm (i.e. compute the entropy first, then compute the password from it). The cli make use of this, so I think it is for the benefit of the cli.
• However, this also complicates the cli. And while it may be neat for playing with the implementation, I don't see a use case for exposing the two-step computation in the cli. On the contrary, experience has shown that complex user interfaces have a cost, and for security tools they may adversely affect the usability and with it increase the chance of making mistakes. In fact, I think the cli should simply be a drop-in replacement for the other LessPass implementations.
• Finally, the API lacks a simple way of computing the password. I imagine sth along the lines of

CharacterSet::default().generate("password", "site", 1)