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

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

3 Likes

You can only lock the first, but what if they use a different secret 2

How can you justify locking out someone from a secret1 when someone elsewhere used a bad password, but these people won’t

What you could do though is have client code that accesses that database and warns the user that their selection for secret1 and secret2 has been exposed for all to see

1 Like

I’m also hoping for UFA.

That would be problematic if users can choose their own password. People tend to choose easy to remember Passwords. Someone might choose username Bob and password password1 and then another user comes to try to register an account with the same username and password.

1 Like

This is akin to Zooko’s triangle. Unique, secure and human readable. Can only have two.

But, if human readable can be sacrificed, then the core can enforce a certain entropy.

2 Likes

how about: xkcd: Password Strength

also a password estimation script, that could be used in the client: zxcvbn: realistic password strength estimation - Dropbox

Please remember that unlike a hacked database where you can run a fast CPU against the stored password to crack it. That is not the case with safe if you use 2 secrets.

First you have to find a record to attempt to crack. This takes say 0.1 to 0.5 seconds to see if there is even a record for each attempt to guess secret 1 (or better with @tfa’s idea of combined) . This could take a very long time at a maximum of 10 guesses a second

Second you have no clue whose account you have, so is it worth trying to crack? It might be one that was never used

Third you then have to crack the account record.


I have suggested in the past that any attempt to retrieve an account record always returns a record that could be classed as an account record. Obviously randomly generated so that there is no way to pattern recognise it is just a dummy account record.

This would change that maximum of 10 per second to maybe 1 per year


In fact returning a dummy record for every failed access attempt might be a reasonable idea since that stops scanning the network for potential hits of data. Helps with obscurity. @dirvine, this could help with security & obscurity on a small network

5 Likes

Yes. 20 chars…

1 Like

This is the most important thing in my opinion… Here is a post I made about how we could possibly use a hardware wallet (read: gpg signing every action in our safe account) Sorry for bad formatting, hope everyone can power through.

1 Like

True, but the UI (and perhaps library too) should never allow such simple passwords to be chosen.

2 Likes

Mm, mentioned this already in post 6.

The post basically says that even if going from 2 secrets to 1 friendly + 1 secret, if hashing location from those, you’d still have the problems of cracking / phishing as well as those @neo describes, making the attacks equal in their infeasibility (as 1 unfeasible operation is not in practice less unfeasible than 2, and if the first operation is not unfeasible stacking two of them doesn’t help).

Yep, mnemonics is generally considered to be more human friendly per achieved entropy.

I originally thought that a btc seed generator was probably a good start for coming up with a passphrase for safe. Not so sure now…

I don’t recall, but will there be a timed network lockout if a user fails to access a valid account after X attempts? Might be good to protect against bot clients…

No and difficult to do because you just rejoin and the network doesn’t know you.

Better to return random data that looks like an account on each try at accessing an account. That way the cracking attempt has to try and crack that returned fake account before realising its a fake. Maybe a or 10000 year(s) to try and break and then move onto the next attempt

2 Likes

I am definitely in favor of this. When I was creating my account, the UI confused me. I wondered, “what’s the difference between these?” I’m just learning the difference now. I ended up generating a password with my password manager and using the same password for both fields. I didn’t want the inconvenience of having to switch back and forth to copy multiple fields from my password manager every time I wanted to log in. I didn’t see any warning telling me that I shouldn’t do this. As far as I know, this is fine to do.

I say those two Bobs deserve each-other.

Maybe, but it should be updated periodically. Maybe the Maidsafe organization could do since they’d have a renewable source of safecoin to spend on this.

I was thinking the UI could potentially perform a secure query to see if a password has been used in a data breach. For example, a service similar to haveibeenpwned (maybe this could be hosted on the SAFE network and be maintained by Maidsafe).

user@localhost ~ $ ./haveibeenpwned.sh 
Please enter the password to test: password123
https://api.pwnedpasswords.com/range/cbfda
Password was found 116847 time(s) in known data breaches.

I’m not sure if this would be effective. How would convincing fake account data be generated?

If it is purely random (e.g. the vault fetches a few KB from /dev/random), couldn’t the cracker ask two different vaults? If the result is different, the cracker knows it doesn’t exist.

If it is generated deterministically (any vault reproduces the same result), the cracker could also generate the same result (and compare against what they received).

Seems that in order for this to work, there would need to be a shared secret salt for all vaults in a section (and a protocol for periodically generating a new one). Even with that, I think a cracker could still create a vault and restrict his search to accounts that are stored in his vault’s section (he knows the salt, and perhaps can search his disk for data having type tag == 0).

1 Like

So, when you request data for an account you actually send an address to the network, and asking for the data at that address. It will go to the nodes closest to this address (in xor-space, not Euclidean distance), which are responsible for that. If you really have your account data there you would decrypt the package that you received. If it’s not your data i.e. you don’t have the secret to decrypt, well that’s when your brute forcing begins.

Thing is, if you are just randomly trying out addresses, you will be slowed down to virtually a complete halt, if you are always sent a an encrypted payload, that for all your knowing is a valid account packet. You’d be stuck decrypting them.

But. Unless the data is deterministically generated, you could just do two requests, and if you get different data you know it’s fake data.
But if it’s deterministically generated, it means it’s part of the source code… so you could also replicate the calculation and compare.

Now, if the vault mixes in some data known only to this vault, the requester could not replicate it. But all vaults holding a copy needs to know this value, and it needs to be shared with new vaults taking over responsibility for the data as they churn, and passed along for ever. Yeah, so the salt that you mention, but not needed for the entire section, just vaults responsible for this data.

2 Likes

It was an idea, without the details. Remember you ask the network for the account, then the network goes to the section, you do not reach out to one of the vaults holding it and ask for it.

Obviously any semi random is to make the returned (fake) account data look like it could be. Basically the size varies randomly but is of a size that would be in the expected range. for an account.

Now here is the beauty with 2^128 possible account addresses, its huge and there is no way any number of attackers is ever going to test even a small tiny tiny portion of them.

Now also the attacker could retry an address and see the returned data is different, but what benefit is that to them? All they can say is that this is encrypted and looks different to before.

Then you keep a marker (eg what @oetyng said) which could be what he said or even derived from the elder addresses in the section. Then the salted deterministic random data generator would give you the same block of encrypted data for an unknown length of time (maybe a week or month or day)

Lets say the attacker is getting 3 per second average and storing the 1 to 100 MB of data to check in 3 months to see if valid and if valid then try for up to 1000 years to crack it. How much data is need to be stored

Average to store is say 10MB and 250,000 accounts per day =>2.5TB per day and then wait 4 months (120 days) to ensure most section elders have changed. That is 1/4 PB of data.

So the attacker is storing 1/4 PB in round robin style to weed out the fake ones then trying to crack any real ones

Now this is 30 million accounts (3x10^7) out of a possible 3.4x10^38 accounts. This is approximately 1 in 10,000,000,000,000,000,000,000,000,000,000 (10^31)

lets say there are an amazing 3 Trillion (3x10^12) actual used accounts for population of 7 billion. Now that means the attacker has approximately a 1 in 10,000,000,000,000,000,000 (10^19) chance of there even being ONE account in that 120 day block of account tries

4 Likes

According to this link, this method is also not super good:

Hashcat has some great concatenating and mangling tools which make passwords made up of multiple dictionary words look rather weak.

→ Best to use generated account secret / password from e.g. keepass. You could use the custom Auto-Type sequence functionality in a recent SAFE Browser. Custom: because an extra {TAB} is necessary to pass the ‘:eye:’-icon. The icon is for showing the Account Secret.

Edit: @oetyng: I corrected the quote.
Edit2: I was a bit too quick → Hashcat etc is of course only useful if you have the hashes of the account secret and/or password…

You got the citation wrong man :slightly_smiling_face:
That was not my writing.

1 Like

So 4 common dictionary words used as a password, such as correcthorsebatterystaple, offers around 5,000 to the power of 4 combinations , or around 6×10^14. EDIT: We’re not sure how XKCD got to 2^44, as a brute force of that would take a maximum of around 2 x 10^35 attempts, which we think was the point he was trying to make .

Hmm… xkcd is using a 2048 words list in his example (11 bits per word / 44 bits for 4 words).

Of course it’s more safe to have a long generated password, but at some point you are going to use a “human usable” password (eg. for your password store) and it’s easier to use a “xkcd” password than trying to “cheat” the system by using leetspeak and all the other “recommended” password bs (resulting in just 28 bits as demonstrated by xkcd). A combination of both might be better, tho.

1 Like