There has been a whole topic dedicated on the subject in the dev forum (Two passwords for login process) and a majority of people didn’t like 2 passwords and would prefer a name (call it common name, account name, pet name, friendly name …) and a password.
IMO the traditional solution (name + password) and deriving both the location and encryption/decryption keys from these 2 elements was the way to go. I argued here and here) but I failed to convince MaidSafe. Maybe you could revive this topic and be more successful than me.
It explains how to build the SAFE Browser with Mock-Vault and how to upload a website using the SAFE Hosting Manager app. We are also planning to add a few code examples that will help you understand how to use the SAFE Browser DOM APIs to build dynamic web applications. We are having some issues with some of the code examples, so we can only publish one of them for now. We’ll update this tutorial with more code examples once we resolve these issues.
Oh yes indeed. I should have also been more explicit and mentioned salting and key stretching… but the intent behind using some sort of hashing instead of splitting is to retain the full password strength for both fields, whereas splitting means each part would be weakened.
I’m not sure of the threat model here. I’d also need to better understand the possible ways to achieve a ‘change password’ feature. I think you make a good point in general - how do users detect and respond to threats to their account security on the safe network?
I think the point I’m making is getting lost in the technical details: the current user interface doesn’t inform the user to make the right decisions and leads to busy work. I’d be fine with two fields so long as I understand why I’m putting them in. Currently I do not and I suspect my account security is put at risk as a result (because I use the same password for both fields).
To really put the dead horse flogging to maximum, my truly preferred method is to behave like a bitcoin wallet - generate strong user credentials by the computer and save them to a credentials file which can be optionally encrypted with a password by the user.
The benefits are many:
the difference between ‘location’ and ‘encryption’ is abstracted and hidden away to the credentials file, which can be extended without having to change their login process (eg add wallet info, multiple accounts, remember app authentications etc)
an attacker must have both the file and the decryption password, whereas with remembered passwords the attacker just needs a network connection and lots of guessing
it allows headless authentication with an unencrypted credentials file, which allows professional users to abstract their security away to the operating system or other system that suits their needs (eg hardware module).
it simplifies the authentication process, since users are only asked for a password, it’s clear what that password is for, and the password is optional
it secures the login for the massive swathe of users who don’t want or know how to use strong passwords. This is most people (even Zuckerberg used dadada for his twitter). Good defaults go a long way.
I know there’s very strong opposition in the maidsafe camp to storing files locally and I fully understand this (even agree to a large degree).
I’m not going to harp on about this any more. The safe network is extremely user friendly in almost all ways. This particular issue can be easily resolved with a fork of the launcher. In the end it’s users who will decide and the current situation isn’t really too bad. Thanks again to maidsafe for the great network.
I’m with you. But I suppose it is from being comfortable with the ways of Bitcoin. Obviously the hard part with this for Joe Mainstream is making sure they don’t lose their credentials, and keeping them secure (and maybe just adjusting to a new paradigm). IMO hardware wallets were a huge step in that regard. Going back to a the old standby of making up, remembering, and typing in a (probably fairly weak) password feels like a big step backwards in security, and arguably usability. As a next gen redesign of the web, I feel SAFE should aim for greater security than what this login method provides.
Obviously I’m not advocating that users should have to buy a hardware device to access the network, just that it should be possible, at least in the future, to access the network in this way.
Protonmail started with two inputs but then found they could get by with one. But understandibly its a much lower bar for a centralized server based email.
You can open a new account and will have a choice of 1 or 2 but standard now appears to be one as the Proton crew said they found new math that allowed equivalence with one and increased convenience.
I have two on one accoount (my first) and one on a later account.
Yes, supporting this would be great. Then the network could be accessed via existing biometric devices too! I’d prefer UAF over U2F though (login directly via the FIDO device instead of using it as 2FA)
Yeah I’m more of the mind to just call it passphrase one and passphrase two because that’s essentially what it is. The username is more your public ID and eventually you’ll able to have any number of those.
has any work been done to help sort out the bugs with connecting to vaults from home? I haven’t been able to connect for a couple iterations now ever since you started requiring port forwarding and all that. Even when I did port forward and had UPnP enabled. Lots of glitches and I have submitted bug reports. I’m just wondering if any work has been done in that direction.
As I understand it, providing uTP support should make connecting to the network a more seamless process and enable more users to run Vaults from home. We are working with an external developer, Carl Lerche, on this project. We expect this work to filter through into alpha 3.
guys, I’ve followed the instructions on safe_browser page, and succeeded in compiling the dev branch. But after I run the browser, no matter if I ran it with $ npm start, or with the released package, the browser’s always asking for the authenticator launcher.
I can see from the output: {"auto_update_enabled":0,"authMessage":"SAFE Launcher does not appear to be open.","authSuccess":false}
Anyone’s having the same issue?
PS. I also tried to reach the safe-auth://home in the browser, but it never opens.
Your collaboration on this will be appreciated. It obviously worked for somebody in Troon in some environment but there are few (if any) confirmations of anyone else getting it to work.