Definitely! But I meant using auto-generated key material in addition to a user-supplied passphrase; it’s as secure on your own computer as it is now (with only the user-supplied entropy), but more secure when attacked from other devices.
IMHO the only valid reason not to use any auto-generated entropy is that hardware can fail and you don’t want to rely on it; I think the design decision here is that you want safenet to be hardware-independent.
This post is created as a continuation of another one which I posted in an inappropriate topic.
Current topic is exactly the one that deals with the problem and after reading it, I think there is a majority of people that have expressed a preference for not using 2 passwords:
During a short period of time a name + password pair was implemented, but then it has been changed to usage of 2 passwords. And worse: not only this has been done in the front end (HMI of the launcher) but an evolution made in core prevents any change of this choice in the front end: now the location of the session packet derives exclusively from the first element which forces it to be a password to avoid collisions between users. Initially the location depended on both elements so 2 different users could pick the same name for the first element (call it the way you want: common name, pet name, friendly name …) but this evolution blocks completely this possibility.
So current implementation forces usage of 2 passwords but I think that the choice should be unblocked at the core level and the launcher HMI should be modified so that each one could make his/her own choice: use 2 passwords or use a name and a password. This could be done for example with a check box indicating that we want to use a common name for the first element and which deactivates the password strength control on it (and possibly reinforces it on the second element).
With this solution everyone would be happy: for example I could use a common name corresponding to the category of account for the first element (finance, travels, music …), but this choice is not imposed and other people could use 2 passwords instead (with strength verification on both of them). And anyone could even use both possibilities, for example I intend to take the latter choice for some hidden accounts.
I agree that the existing system is relatively unwieldy for users, but I would prefer a single robust and easy to use/understand system rather than adding options that I think will complicate it further.
I agree it will be important to have a friendly name for each account, but this doesn’t have to be part of the login - I suggested elsewhere having this as a setting within account metadata, which could be accessed and displayed (and edited) by apps. So that’s another option.
One question is: do we need two passwords?
I don’t think either is easy to solve. Both have implications for implementation, usability and security in their different ways.
Good to raise this because it’s important - one of the most crucial factors in initial impressions and overall usability.
The preference of many people (and mine) is to have one name + one password. But Maidsafe sees benefits in having 2 passwords, so I proposed an option to please everyone.
I agree that this option is a complication, but it’s only one check box whose label has to be carefully worded to make things clear. Besides it doesn’t impact the robustness of the product because it’s only a matter of HMI and the data flow remains basically the same: 2 elements sent to core that transforms them into the 3 legacy elements (keyword, pin, password).