Only got 2 at the moment…
- Use an existing but unuse public (unshared)/private bitcoin key pair that’s already heavily backed up. This would calm my fears of losing my core SAfECoin stash…
- UUID generated string for public and private
Only got 2 at the moment…
I usually make it up using the initials of a phrase that I know I will remember, mixing with numbers and symbols following a pattern that I know I will remember too
Like the title of this post would make something like :
Maybe using dice and a word list like explained on the EFF site here.
I use keepassXC to generate my account secret and password in 4 steps.
All authentication systems I know require only one password (or passphrase, secret …, name it like you want), that is a string which a strong unpredictability.
Stating that an account needs two of them is an extraordinary claim and, as we say, an extraordinary claim requires extraordinary evidence, but @maidsafe didn’t provide one.
There is this topic that tries to demonstrate this by stating that 2 passwords are more secure than one. But:
Lastly, @ustulation made a logical error when he argued that usernames have drawbacks “
if people can easily guess where your account packet is in the Network it narrows down the attack vector to just decrypting that packet”. This is true when account packet location is derived only from username and @neo suggested to derive its location from both password and friendly name to solve this problem. @ustulation seemed to agree with this, but we are still with a password and a secret after 3 years.
This post is another attempt at it and I wonder if one day @maidsafe will come to reason on this subject.
The source of the address could be the combination of the username and the password (by any method).
I think it’s correct though that two independent strings s_0 and s_1 with equal entropy E_1, will be significantly stronger than one short string s_3 with some entropy E << E_1 combined with another string s_4 of E ~ E_1, into address source.
You’d only need to spend lot of effort on s_4 and then you’d probably find s_3 quite easily with a rainbow attack.
But, unless cracking s_4 isn’t practically unfeasible, it doesn’t really matter either way, I would say (and n that case, it seems a too lenient entropy enforcement has been used).
If it is unfeasible it would come down to social engineering, phishing and such (because 2 times unfeasible is not much different from 1 times unfeasible), and at that point I dont think there is much difference in gaining only one or both of s_0 and s_1.
Edit: so what I mean to say with all that, is that in theory it is as ustulation says, more ‘secure’ with two ‘passwords’. In practice though, due to the above described, I’m not so sure that it would make much difference on the number of actually compromised accounts, given same pressure level from malicious actors.
If I am not mistaken (ie i could be wrong ) The idea is to allow changing the password which would not be possible if either just password or password/friendly name is used.
I can see some reasoning behind the needing two elements with one for the account record and one for the unlocking of it.
Now does the location need to be a password? That is the question here I see.
So what I can do now (if the strength tester allowed) is to choose the first (location) to be Robsaccount and the second to be a strong password
Now the problem with that is collision with any one of a few billions other accounts
What he meant was that you transform username with the password (s_0 and s_1 in my post above). You could encrypt it with the password for example. The result is used for location. That way it depends on s_1. You wouldn’t have collision other than with exact same combo (other than the inherent collisions with the particular hashing done, presumably negligible).
Changing password would regardless be possible by copying the account packet to a new place, and deleting the old. (IIRC it was deletable)
And this prevents changing your password doesn’t it
Still one of the issues is going to be collision. How many people are going to choose the same password. Since many will use a phrase that they can remember its most likely that some people in the billions of accounts will use the same phrase and there needs to be more randomness. Thus two fields
I wouldn’t say so. If changing password in today’s world is replacing a value in a db, it’s the same thing in principle here - replacement of a stored value, just some other value. Account packets are not supposed to be big I think?
Nopes. You need the exact same username and password to get a collision on the location. So that should not be more likely than collision on a pwd-like location from start.
Yea, I edited my post while you wrote yours. Sorry for the mishap
I thought we were talking of one field and that was password - my bad
Oh ok, sorry I misunderstood what you were talking about then.
I think @tfa meant using password (high entropy) to transform the username (low entropy) into a high entropy location. Anyway, if he didn’t, that is still a possibility
Edit: It gets quite interesting when both are fast editors
To clarify my position, current implementation:
What I propose:
Edit: Password can be changed in both current and proposed implementation because account packet is a mutable data.
Account data changes regularly. EG new IDs, new datamaps etc
I do like this as I have in the past
You are right, account packet is a mutable data, so no improvement or regression in this area: password can be changed in both current and proposed implementation. I will edit my post accordingly.
So the friendly name would be unique for each user then?
No whatever tthe person wanted
It is the combination of password and friendly name that needs to be unique
Exactly. With this proposal, many people could use the same friendly name (“David”, “Finance”…)
Should the network pre-burn leaked username/password combinations that are already out there?
Don’t think we want people stating they were “hacked” on the most secure network ever made?
Edit: Should we prevent early dictionary attacks?
I’m still holding out hope that hardware authentication (E.g. fido-u2f, etc. ) is implemented.