Safe authentication considerations

Not specifically you if you don’t communicate it. I am just saying that you don’t need your secret to be strong.

But at least, can we agree that account location should be derived from both elements?

There is no pin anymore, but we get the idea. This is currently unfeasible because the same user cannot have 2 passwords.

But if Maidsafe implements account location based on user + pass, then this would open some possibilities:

  • Firstly, a simple workaround if you manually copy public data between both logins. But this is far from perfect.

  • Better, if the 2 accounts get parts of the same BLS 1/2 multikey, then the public data could be shared and “appended” in real time simultaneously in the 2 accounts. But I am unsure of this because I haven’t studied BLS cryptography and I may be cut off from reality.

1 Like

Perhaps we are are misunderstanding what username is?

There is no username / user + pass. It’s just pass + pass.

1 Like

Sorry that I was unclear. The login for connecting to an account has 2 elements and currently:

  • they are named secret and password
  • they both need to be strong
  • account location is based on the first element only

My proposal is to base the account location on the 2 elements instead. In this condition the first element doesn’t need to be strong anymore and could be renamed to username, friendly name, pet name, …

This would open new possibilities like distinct users having the same username (like Jim, photos, bank, music, …) and plausible deniability mentioned by @piluso.

The use case he described is precise with 2 logins having:

  • the same username
  • distinct password
  • common public data
  • different private data

In my response I said it might be implemented with manual copies of the common public part or with BLS keys, but I am unsure of the latter.


Nice discussion… maybe it’s gone off course :wink:

I’d prefer to just have one single login credential that has all info needed rolled into one. With restrictions on min. length (fewer types of characters, longer length). Maybe some other tests for randomness when creating.

I’m no expert, but keep it as simple as possible where possible.

readable account names, user names, etc … should all be inside the account, not visible on the outside of it IMO. If a user needs to name their account, then use a password manager and name it in there.


I like the concept of having a short easy username… So then the point about “both need to be strong” becomes “username can be anything, passphrase needs to be super strong”. Best UX so that 256 bit or 512 bit credentials are easy to manage? 4096bit RSA private keys? Mouse clicked pictograph? 512bit hash of a file? I think we need to move beyond the keyboard.


Yes, and after a certain point, there is no point in making secrets or passwords / passphrases easier to remember, because they are already far beyond what we normally can handle. At that point we are already making use of a pwd manager for example, and we can just as well max out on the secret strength (makes no difference in UX at that point).
And if we can locate this super strong secret, with a very friendly name. So then… that’s good UX, no?

Compare to having 2 medium strong secrets, they probably need to be stronger than your mind can handle, so you haven’t avoided the pwd manager. Also, you cannot locate them easily, without adding yet another component - a friendly name. So now you have 3 components.

So… this proposal by @tfa, already as I mentioned back in the topic he links, if correctly implemented, is more helpful IMO.


Microsof is even trying to push not using passwords in Windows anymore.


An item on my wishlist is something akin to UFA.
The login by typing in one or two things approach is very vulnerable to key logging. If SAFE comes to hold a significant portion of our sensitive digital data and/or wealth, this would make me quite uncomfortable. In the broader crypto space we’ve become accustomed to using hardware that protects you even in the case that your PC is compromised. Ideal UX for me is launch browser, click a button on hardware to acknowledge login, done! Or maybe on mobile launch browser, complete biometrics, done.

1 Like

Sounds like we need a thread on all this.

Slightly out of scope for this particular body of UX work, but worth hashing out.

Terrible pun, sorry.


Yes, going off topic a bit. We have this one already.

1 Like

I moved the relevant posts (I think) to this new ‘Safe authentication considerations’-topic.


It has been discussed several times here about 2FA:


Now with FIDO2 released, the adoption of hardware tokens for passwordless access will probably become mainstream.
I think it is time to think about this once again, as it is the few remaining weakpoints of the SafeNetwork, tailored attacks by phishing and keylogging.

If these vectors are removed, I think that there is no “traditional” attacks remaining that could be used for the SafeNetwork.


very nice :smile: and very stronger security happy

As we’ve seen with hardware wallets, this means you rely on the security of the hardware/bio device. As with any hardware the possibility is there for them to be compromised and maybe even widespread compromise where any system secured by the device is now open to crackers.

I am not against there being a wide range of methods to access your account and leave it up to the individual as to which method they use.

Hardware needed means a higher barrier for those who barely afford their essential phone device they use for everything from communications to all their internet. To then make them buy (typically many times the real cost) a hardware device just to log in is going to hurt.

But as I said before, sure lets have many options.


I’d be interested in enabling a two factor Something you have + Something you know approach, but I agree, while having a single factor is a better UX, does it perhaps increase the risk too much?

The something you have could, of course, be the device itself, and you could specify no auto-log-out, to make logging in less frequent, and thus more convenient. Or we could use FIDO or somesuch.

That could maybe deal with the account secret, and then just leave you with the password, as something you know.

1 Like

I had thought of a USB device that had your account key encoded on it and the section you connect to initially sends a challenge to the computer which passes it to the device and the device uses the challenge and signs a response which also includes the account record address and the user enters a passphrase or pin to counter sign the request.

Then to decode the account record the USB device could help there too making it easy for the user.

On a side note, something that has come up regularly in Usability testing is people not really understanding what “Account Secret” means. Some participants during on-boarding even wondered if it was some secret about themselves that they had to provide, and this was a bit unnerving. Or they wondered if it was something they should already know, and thought this field was a question!

Amazing the insights you get when you observing people using things.

So, we are testing alternative labels for that. Front runner is “Passphrase”, so you’d create a Passphrase and Password, during on-boarding.

We’ll keep on testing though, especially when we return to work on log-in and on-boarding UX again.

1 Like

I tend to agree with @tfa about the first being a name (pet name, username or whatever) and use the password combined to derive the account address. I would though suggest that there is a minimum character count for the first so that we don’t get the occasional hit because people used name as “fred” and password as “thisismypassword”

I don’t really get this TBH. I mean, it seems to me it would then make your account wide open to individual targeting.

Unless I’m misunderstanding.