This is very very awesome, and needed 
Great work 
2 Likes
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.
7 Likes
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.
8 Likes
100% agree with you there.
10 Likes
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.
2 Likes
Yesterday I still needed to give two ?? One to logon and one to decrypt locally ? Maybe itās changeable or why you have one ?
On safenet I think it should be coolest to have option between passw or passw+hw solutions 2faā¦
2 Likes
Has anyone actually managed to follow the tutorial and get the web_hosting_manager to work?
This is how I and a couple of others are strugglingā¦
trying to follow the tutorial
But donāt get me wrong, Iām having LotsOfFunā¢ trying
Thanks guys and gals
And possible it should be. Adoption is growing in U2F FIDO
2 Likes
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.
1 Like
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)
1 Like
Biometrics are avail on android/ios clients. no clunky=ez adoption, heres hoping.
1 Like
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.
1 Like
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.
8 Likes
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.
3 Likes
Yes - please check out this thread following the OP in the dev forum - these should never have been split IMHO
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.
3 Likes
Thanks, @Southside. Iāll ask there.
2 Likes
Finally, figured that it had something to do with my cargo path, thus $ npm pack authenticator didnāt finish correctly.
Now Iāve got the new browser with the built-in authenticator up working smoothly. Yay!
Iād also like to share the link to the Mac version.
6 Likes
I got that far (on Debian). I also built the SAFE Hosting Manager, which runs but doesnāt manage to display anything, or to cause the Authenticator to do anything - as [noted in the Dev forum] (How to build the SAFE Browser and upload a website with Mock-Vault - General - Safe Dev Forum) - better we keep to one topic and I think thatās the preferred place for detailed technical stuff.
Thats pretty much where I am too on Ubuntu 16.04.
1 Like