Safe 2FA/MFA Brainstorming, Key Management and Self Authentication

Features
61

Thinking about what questions could be asked to the user, which will not be vulnerable to key loggers - could we have a user definable algorithm asked?

This could be as simple or complex as the user wishes to make it, but something like these:

x + y
concat(x, y)
concat(x * y, x)
substring(reverse(concat(x,y), 5)
hash(substring(reverse(concat(x,y), 5)) // one for a hardware device or local software script maybe?!

etc.

Each login, the input values for x or y (for example) could be presented to the user and the user would have to calculate the output.

Obviously, an eves dropper could derive the value of x and y over time, but it wouldn’t be obvious from a single login attempt. Brute forcing could also be an issue, but with sufficient complexity that would be hard (and the user/pass already makes this tough).

The algorithm would need to be easy enough not to be a PITA, but hard enough to provide protection.

I suppose this falls into the ‘something you know’ category, but instead of it being something someone could guess or a hard coded list, etc, it is a bit more nuanced. The user could rotate the algorithm over time too (again, as frequently as they desire for security vs difficulty to remember).

This wouldn’t require any writing of data (unless the user changed the algorithm) and nor would it require a second device (for good or bad). I suppose you could use a second device to store the algorithm, which would allow them to be more elaborate/challenging, but even that could be on local device storage.

1 Like
62

General biometrics for interacting directly with the Safe Network is a bad idea. 1) You don’t want the ability to access the account tied to possession of certain body parts or images, 2) You don’t want the extra hassle of supporting biometrics algorithms, software, and required hardware, 3) You don’t want to transmit some form of a basic representation of your identity like biometrics over the internet.

Biometrics can add a lot of security and ease of use for MFA access credentials under certain controlled/local situations. For example, consider a secure building with an armed guard and dedicated biometrics system for opening the door. Another good example is a dedicated hardware key that requires a thumbprint to show a one time password. Unlocking your phone with a thumbprint or face instead of a n-digit pin number is a gray area. It works because the hardware and software are baked in to the system you are trying to access and only makes sense if you are too lazy to use a 16 digit pin and/or are unworthy of being a target.

@neo has made some really good comments about the need to keep it simple so that access is possible on any hardware platform. That doesn’t mean fancy hardware can’t be used to assist, but the techniques must be reducible to printing MFA keys on paper to have the ability to use solely a keyboard and mouse for worst case scenario.

@traction’s post about solving a challenge puzzle is a good example of something you can do instead of something you are.

Yes, that’s where this discussion is heading.

63

I agree, but it could be useful for either unlocking keys or MFA on mobile. In a mobile password manager for example, you can usually choose to unlock with biometrics most of the time and only occasionally be asked for the master password or you can choose to enter the master password each time. If you choose to unlock with biometrics, the master password for uncrypting is stored in the app and can be unlocked with biometrics without the user having to type it each time.

64

I’m arguing there are circumstances where you’d want exactly that, for additional factors, precisely because it rules out the possibility of remote attacks, neuters key loggers etc. This will depend on an individual’s threat model, and how they use the Network. It need not be the same for everyone.

I’m not suggesting this. But using biometrics, or (multiple) hardware devices / paper, as additional factors on top of password+passphrase will thwart huge number of attacks.

Let’s just say FaceID on my iPhone could be thwarted by a photo, which tricky and high cost, but maybe just possible. An attacker would need:

  • To know that I specifically have something valuable on the Safe Network
  • My Password and Passphrase
  • Access to my iPhone (unlocked with PIN)
  • A detailed picture of my face

So really when it comes down to it, this is a rubberhose scenario, which I’m afraid not really any MFA schemes will save you from; and the only way to escape the hose is probably to have soft enough security for attackers to get what they want without resorting to it, which is a solution to that extreme scenartio, but obviously opens up lower cost attacks too.

But what if I’m hiking in Nepal I hear you cry! Well then you could just fall back to less convenient additional factors such as ‘unknowable’ paper tokens, YubiKey etc.

1 Like
65

I’d agree with this, although the way you are describing it it is really just a suped-up single factor, and it should be viewed as this: a way to encourage users to have a usable Password and a super strong Passphrase, to have better overall security, but make it convenient to use: which is a big hurdle in getting people to create strong credentials.

So strong credentials would be like:

Password: detach7tussle6shortly
Passphrase: zoology-sprawl-monk-drawl-vellum-sceptre-inferno-woollen-hotrod-calm

So both memorable and knowable, but typing out that second one every time on a mobile is gonna be a pain. Secure it with with biometirics though, and it becomes a lot more viable for day to day use: I type the password one each time, but the passphrase is filled for me. And in a pinch I can still type it all out if I’m on a shared device.

But this is still only single factor stuff; although a consideration for making that single factor secure an a bit more usable.

1 Like
66

Biometrics can also be useful for unlocking 2FA, say unlocking an app with 2FA codes or a hardware device that needs your fingerprint to open etc. Some hardware wallets come with a fingerprint sensor to be used instead of,or in addition to, a pin code.

1 Like
67

I agree, and as long as this is local only, never transmitted anywhere beyond the hardware device itself and never stored etc. then it’s more likely safe. Still needs care though and I wish there was a standard spec for secure biometric devices (so no memory reading/bus leakage etc.). Then though I think they are really good.

4 Likes
68

Yes, similar to the example I gave here.

Good to know . That wasn’t clear earlier.

Yes, this is my opinion also. The only good example I know of is a smart stick or smart card with a thumb reader that exposes a one time password for 2FA. The biometrics never leave the hardware and/or there is an air gap, the thumb print makes it MFA. Years worth of OTP can be printed on paper for a backup if you lose the stick/card or don’t feel like using it. Using a phone for this is better than nothing, but as dirvine said, this needs care.

3 Likes
69

I changed the thread topic to be more general. I think we need to consider the entire key management chain used for self authentication and how it relates to MFA (as @mav previously alluded to).

3 Likes
70

Security is only as good as the easiest fallback method to crack.

71

But in this case, the hiking example isn’t necessarily easier to crack, just less convenient to use.

1 Like
72

Is somebody (a dev?) willing to give a quick synopsis of how the most recent implementations for the account locator and passphrase (passphrase & password) are used to perform self-authentication? Has the self-authentication process changed with the advent of crdt? Have things changed due to BLS? I’m perusing the sn_client repo and it isn’t entirely clear.

1 Like
73

Password and Passphrase are supplied by the user.

These are then used to ‘derive location and keypair’:

https://github.com/maidsafe/sn_api/blob/c2c6716d29e56f387776202dad94ddda9b8fe2b2/sn_api/src/api/authenticator/mod.rs#L63-L74

Within that derivation, there’s an additional ‘derive secrets’ (duplicated by sn_api and sn_client but will be consolidated soon hopefully to use only the sn_client version - sn_api/issues/714):

https://github.com/maidsafe/sn_client/blob/e6b65d62d8a42912823275c571620fd57df77552/src/utils/mod.rs#L150-L159

These secrets are then used to ‘generate network address’:

https://github.com/maidsafe/sn_api/blob/c2c6716d29e56f387776202dad94ddda9b8fe2b2/sn_api/src/api/authenticator/mod.rs#L84-L97

and also the keypair:

https://github.com/maidsafe/sn_api/blob/c2c6716d29e56f387776202dad94ddda9b8fe2b2/sn_api/src/api/authenticator/mod.rs#L71

So no BLS, only ed25519.
CRDT has not changed the derivation of account details.
This can be done any way the client chooses, the sn_api / sn_client way is just one way of doing it.

The user needs to supply a location and a keypair. We currently happen to be deriving these from password / passphrase. I can easily see this changing in the future.

12 Likes
74

Thanks @mav for the push in the right direction. Correct me if I’m wrong here:

  1. The account password and passphrase will never leave the client device. They are used in a deterministic way to define the account location on the network and encryption keys.
  2. The derived ed25519 key-pair will be used to secure communication between the client and the rest of the network using asymmetric cryptography.
  3. All that really matters is the account locator and ed25519 key-pair. If desired, these could be supplied independently to the network without the use of a password/passphrase for deriving these deterministically.
  4. The password/passphrase combination in its current form is analogous to a typical blockchain wallet seed that is used to deterministically derive a variety of blockchain addresses.
5 Likes
75

Yes the client retrieves the blob at the address and then decodes it in the client

3 Likes
76

1, 3, 4 are quite right. Number 2, depends a bit what you mean by ‘communication’…

Keypair is used to decide which section the client will connect to:

https://github.com/maidsafe/sn_client/blob/e6b65d62d8a42912823275c571620fd57df77552/src/connection_manager.rs#L470

Also for signing requests to the section elders:

https://github.com/maidsafe/sn_client/blob/e6b65d62d8a42912823275c571620fd57df77552/src/connection_manager.rs#L447-L460

And is the basis of the client wallet for performing write operations:

https://github.com/maidsafe/sn_client/blob/e6b65d62d8a42912823275c571620fd57df77552/src/client/mod.rs#L76

The only place I could find communications being secured was in qp2p, which does not use the client keypair:

Maybe I’ve missed somewhere else that does more encryption to/fro client/elders, but to my understanding it’s only encrypted by qp2p, not the client keypair.

Safe Network routing is quite different to TOR ‘onion’ style routing. In Safe Network the client doesn’t know the full route so they can’t pre-compute the layers for an onion-style route. The privacy in Safe Network is because the route knows the client xorname but not the client ip. Every hop of the route knows the client xorname and the data xorname, but not their IPs. Whereas in TOR the first hop knows the client but not the url, the last hop knows the url but not the client, and middle hops know nothing at all. This may change in the future.

This has gone fairly off topic but anyway, hope this helps show the purposes for the data that 2FA/MFA will be securing.

Happy to be corrected on any of this. I know some parts of the code very well but others not so well and I may have missed something.

7 Likes
77

This is a useful summary, I think.

Given that once the key-pair has been retrieved, access is assured, I feel any 2FA check must be integrated into step 1. Doing anything after this fact would be like closing the gate after the horse has bolted.

I suppose the client itself could store the 2FA logic directly. This would essentially ‘unlock’ the client, but any key logger could then install a client without this check and just use the subsequently entered password and passphrase directly. So, this seems unsatisfactory.

Therefore, it seems like a mechanism to take input of (from keyboard) something predictable (but different) and transform it into the same result (location) is required.

Food for thought!

78

Thinking about this some more, a hardware device would offer a good solution here. Given you want to either type something different each time (stop key logger) or type something in which is useless to the key logger owner, this could work.

If the location of key-pair was encrypted and stored on a personal security device, the safe network client could request the passphrase for the device instead. The client would then retrieve and decrypt the location of the key-pair. A wired connection to the device would provide maximum safety, but a secure wireless protocol would add convenience.

If a key logger was present, this passphrase would be useless without the device holding the encrypted location. The passphrase on the device could also be rotated easily, without causing a change in location.

I’m sure some of those hardware dongles do something like this. At a primitive level, a mobile phone or USB stick could would fine though. A mobile phone could even have a UI to easily change the passphrase. A dedicated dongle may just have a PIN to reset instead.

Edit: Actually, couldn’t the private key just be stored on the security device? If the private key was never stored on the network, once you were logged out (i.e. client closed) and the security device was removed, no one could derive your private key. That would prevent anyone reading your data or signing other data without your security device being present.

4 Likes
79

Thank you for helping everyone see the mechanisms at work and for pulling in quicp2p @mav. I think this is very on-topic since everyone now has a good basis for where the keys are and how they are used. Now we can have a proper brainstorm about MFA key management details and strategy.

The final clarification I think we need to establish is that the password and passphrase are analogous to the 24 word mnemonic seed often used by blockchain wallet software like electrum. Is this a bad analogy? Is there a better way to think about these? Passphrase/password length is not currently enforced, why?

Edit: Is this more appropropriate/clear for item 2 above?

  1. The derived ed25519 key-pair will be used to secure communication between the client and the rest of the network using asymmetric cryptography. (The ed25519 key is used for wallet transactions, section membership dynamics, puts, and gets… TLS 1.3 via quicp2p used for raw node to node UDP .)
4 Likes
80

I think this post from neo in another topic is also relevant for this discussion.

1 Like