What is a good strategy for choosing account secret and password?

Autonomi Network Token (incl (e)MAID)
1

Only got 2 at the moment…

  1. 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…
  2. UUID generated string for public and private
  3. other…
1 Like
2

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 :
Wi1gS4cAs+P

1 Like
3

Maybe using dice and a word list like explained on the EFF site here.

3 Likes
4

I use keepassXC to generate my account secret and password in 4 steps.

  1. I create a new element in my created Safenetwork group.
  2. I generate a password.
  3. I copy it to my username value and use that as my account secret.
  4. I generate a new password, copy it to password value and press OK.

Done.

2 Likes
5

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:

  • No proof is provided
  • Most people are against this principle (see my recap of quotes here)
  • This prevents friendly names that could be used by people to create several accounts like “Music”, “Sport”, “Finance”, “Business” … (possibly with the same password)

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.

Several times I have proposed to go back to the standard usage of password + username (or friendly name, pet name, … call it like you want), see here or here.

This post is another attempt at it and I wonder if one day @maidsafe will come to reason on this subject.

3 Likes
6

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.

1 Like
7

If I am not mistaken (ie i could be wrong :slight_smile: ) 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

1 Like
8

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)

1 Like
9

And this prevents changing your password doesn’t it

Yes possible

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

1 Like
10

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.

1 Like
11

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

1 Like
12

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

Edit: It gets quite interesting when both are fast editors :smile:

2 Likes
13

To clarify my position, current implementation:

  • credentials are composed of a password and a secret and both must be strong
  • account location is derived from secret
  • decoding key is derived from password and secret

What I propose:

  • credentials are composed of a password (strong) and a friendly name (weak)
  • account location is derived from password and friendly name (so, no risk of collision)
  • decoding key is derived from password and friendly name

Edit: Password can be changed in both current and proposed implementation because account packet is a mutable data.

3 Likes
14

Account data changes regularly. EG new IDs, new datamaps etc

I do like this as I have in the past

1 Like
15

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.

1 Like
16

So the friendly name would be unique for each user then?

17

No whatever tthe person wanted

It is the combination of password and friendly name that needs to be unique

2 Likes
18

Exactly. With this proposal, many people could use the same friendly name (“David”, “Finance”…)

1 Like
19

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?

5 Likes
20

I’m still holding out hope that hardware authentication (E.g. fido-u2f, etc. ) is implemented.

3 Likes