MaidSafe Dev Update - May 4, 2017

I completely agree with you.

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.

7 Likes

We just added this tutorial to the SAFE Dev Forum:

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. :slight_smile:

15 Likes

This is very very awesome, and needed :slight_smile:

Great work :rocket: :rocket: :earth_africa:

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 :slight_smile:

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