Obviously YES
The account address is derived from your Name+Password. So there is no way for someone else to know the address without both the name and Password.
For the current system they only need your “secret 1”
1 Like
Let me break down what the attack I think could result, for regular, non-tech users.
- The first question at on-boarding is “create a username” for your account. or similar. It’s likely that they will be inclined to re-use a username that they’ve used on the clearnet, or that someway reflects one of their identities.
- They choose a password. Could be strong, but there is a chance it might also be weak, or it might be one we can programatically show to be strong, but maybe they’ve reused it somewhere before, maybe on the clearnet.
- Their account is created, and they go on to create an identity for themselves, by setting up a profile/SafeID. There is a chance here also, they may choose a similar, or connected name to the the username they created in 1.
So now, a hacker, corp, or state wants to target this specific individual. What tools do they now have that that would allow them to gain access to this users account?
- They could take all known variants of the individuals clearnet identities, and use them as usernames to brute-force or dictionary attack to gain access.
- They may try the same by using the individuals SafeID as the username, too.
- They may know the passwords that this individual uses on the clearnet, and use them to do a really specific dictionary attack—knowing that it is quite common for users to re-use passwords—on a small set of usernames and variants they’ve derived from the clearnet and SafeIDs.
This is all possible, because we give attackers a starting point of a “username”. But if both parts to the account login are secret, and only ever known to the individual user—and we describe them as such—then none of the above are attack vectors.
Again, unless I am misunderstanding the proposal.
Everything you said there is also applicable to secret1, secret2. So the other idea is no worse.
The user you described is lazy so for secret 1 they choose a familiar username for secret_1 as you said for username and for secret 2 they do the same as you said for password
So now all the attacker has to do is cycle through known usernames without passwords and can gather a large number of account records to attempt to crack.
secret1/2 is much easier to crack when considering your lazy user
BUT you say you force strong secrets, then do the same for username and password and then the difficulty to get an account record is much higher.
But, this is far less likely as we are not prompting them to create a “name”. Names, by definition, are not private/secret, so we are opening up this vector through our choice of language.
You guys I’m sure will get fed up with me on the specifics of language, but it matters a lot to UX, and it matters to security.
So we call it “Passphrase” + “Password” and it becomes no more technically secure, but it becomes more secure in through its UX.
I’m all for making things technically more secure too BTW, so if there is a way to do that through deriving the account address though a combo of the two elements, then I’m all for it (implementation of all that isn’t my department though), but it would be a shame to undo all that extra security through making an account less secure though poor UX.
And again, we can force more secure passwords etc. but this is also rendered pointless if we have poor UX e.g. by calling something that should be entirely secret to the user, a “username”.
2 Likes
BUT even having the account address derived from secret1+secret2 is more secure than just using secret1
I’m not arguing against that.
My argument is about what we call secret1 and how we present its use
2 Likes
Yes I do see your point and I will leave it here since @tfa has put a lot more thought into it than myself.
3 Likes
Incidentally, and just for info, ProtonMail (end-to-end encrypted email) have a username plus two passwords, plus an option to use an authenticator app with a number of one-time codes should the user lose their phone. Two-factor authentication (2FA) . Nothing for Yubikeys as yet though.
It seems like the authentication market is evolving quite fast with biometrics and AI and it would be wise to keep as many options open as possible, as I think Jim mentioned earlier in this thread.
3 Likes
IMO Secret 1 should be an identifier for how the user plans to use the account. For example, it could be a “personal” account or “business” account, or some other easy identifier that is personal to the user with regard to a unique project or subject title. It should be ok for millions of users to have the same secret 1 such as “home”. Secret 2 should be an extremely strong passphrase with enforced length and complexity (ex. 4096bit ) similar to bip39 seed or a SAFE equivalent that is clicked on the screen via a glyph table, or supplied via hardware key.
3 Likes
This is a side topic really, but I don’t think the user should need to silo these different usecases into separate accounts.
There could well be the facility in future to have different account ‘profiles’, for different contexts.
But we should be working to facilitate the ‘1 Unique Human = 1 Account’ UX. With all that SAFE enables, the user shouldn’t need to have multiple accounts and multiple passwords (probably then having to rely on a single password manager), any more than they’d need to have multiple brains.
2 Likes
Sorry in advance to not have (re-)read the technical considerations concerning the Safe Authentication and to possible repeat points others have already made.
What is the real added value to have a ‘pet name’-field in the authentication?
If I understand this correctly, it is showed nowhere when/after you log in on the SAFE network. One advantage I could see is if you have multiple accounts and you want something to identify the account. But if you memorized (good) password(s) or passphrase(s) of these multiple accounts: well done, you have a better memory then me. And I’ve no doubt if you’ve gotten this far, also remembering which password belongs to which account is no problem. And when stored in e.g. a password manager: enough possibilities to make the distinction without it needing to be in the password(s) themselves.
So if no added value: better call it ‘password 1’ instead of username or ‘account secret’.
Concerning 1 versus 2 passwords: Is there a realistic scenario a ‘hacker’ can get the first password (hash), but not the second (or vice versa)? Or is there a (future) scenario that one part remains unchanged (e.g. location), but the other part of the password can be changed? If the answer on these questions is no I’m inclined to go for 1 password.
Another question (that is undoubtedly discussed in the past here): is a ‘multiple sign’-kind password somehow possible? Or a ‘backup’-password you store safely (and on multiple locations) right after account creation that you would only need if you lose your daily usage password?
2 Likes
I
True, but that is not sufficient for many use cases. Example, you can’t have the same account for “business” use that you have for “personal”, profiles under one account is not best practice. So there is going to be more than one account per user. However, the more features you pack into an account will minimize the accounts per user ratio.
All good points @draw. Simplest/Best to just have one really strong passphrase and let the user manage pet names on their own.
3 Likes
Why does this need to be bad practice though?
I mean, you don’t need to carry two laptops around with you, one for business, one for personal. If we think about your Safe account as a hardware in the sky (with a single log-in), and then a profile could just be applied for you to switch contexts.
If you’d prefer to think of it like sub accounts, then cool, but I don’t think there is a need to burden users with multiple logins by design, if we don’t have too.
How about each account just having one strong password? The confusion seems to be we are used to two things u+p, and SAFE follows this, but in a way that is not consistent with the existing pattern.
Do we need u?
It not, do we need 2x p?
If not, why not just one strong p?
It is different, but it is also simpler. If you want more than one account, you just need to manage the passwords, not remember which goes with what.
We can then implement profiles within an account to help manage data/context within one account and lessen the need for people to bother with multiple accounts.
4 Likes
Many people do, otherwise your personal data becomes company/business property.
Yes, lessening the need for multiple accounts is fine. But forcing a one user one account rule is not good.
2 Likes
Luks containers on Linux offer the ability to add/remove/manage passphrases and keyfiles used to unlock a SSD/hdd partition. I’ve often wondered if a similar feature would be good for SAFE.
3 Likes
True enough. Any attacks I’ve seen, like the recent Trezor vulnerability, required physical access to the device. Once the attack becomes known, it is likely that the user would have enough time to migrate to a different device etc before being effected.
+1
Yes, this is pretty much what I’m thinking too.
The key points: offline secret generation, offline secret storage, offline transaction signing.
+1
No need to fit into the old (broken) paradigm.
1 Like
Someone with better maths/sciencing skills than me could perhaps explain how I’m being dense here but, if all users only have one password, and the parameters are known, how does this not just turn into a dictionary attack goldmine? Unless we are talking XOR address level complicated, and in that case, not terribly human usable/memorable.
Also, with just a single login element, I can’t be for-warned that one of them might have ben compromised… through an attempted log-in notification, which could then prompt me to change it.
Additionally, if there is only one, the system would have to notify a user during account creation if a password was already in use… aka they now have access to someone’s account. (even if a remote possibility)
If there are two or more elements, I can simply be told “choose a different combination” and I don’t know which one has a collision.
2 Likes
It’s not too different than trying to guess private keys of crypto addresses - If you have good randomness, the search space is just too big for any attack. If you don’t have good randomness, you’re going to be in trouble, regardless of 1 or 2 words being required.
What’s the difference in randomness, or password complexity requirements for 1 vs 2 phrases? Say if we are using a string of memorable words in a diceware password stylee?