Reverse Brute Force Attack On SAFEnetwork Credentials

Reverse brute force attacks are possible on SAFEnetwork, highlighting the need to choose password wisely, and to consider using hard to guess keyword and pin.

For example:

  1. choose a password you expect someone is likely to have used
  2. attempt to brute force the keyword and pin

This is not able to be targeted at individual users, but will be effective for users who choose poor passwords along with a dictionary keyword, and smallish pin.


A brute force attack would require a great number of login attempts in a short time period.

Is there not a simple way of preventing this by locking out an account for a time if too many incorrect login attempts are made?

I wonder if the bootstrap peers could cut off communication after so x many requests with no results returned.

A login is actually a request for a file as I understand it – The credentials are not sent to the network, the client just hashes them together to build an address to query to find it’s stuff…

This means brute force attack by choosing a password eg, "12345678"
and running it against logon’s names?

IDK, because SAFE isn’t like some little app or service, it’s the whole internet, and I think it’s pretty wrong (and hard) to “lock” someone out of the whole internet.

Decrease their rank? Maybe. But bar then from the internet? I hope not

1 Like

I would expect that the time from entering the password to the time your account info is retrieved is going to involve many hops between the client -> Group -> datamanagers -> vaults -> … nodes … -> client. You tell me how many milli-seconds will that be? My guess is much more than 100mSecs, especially if the client’s group is spread across the world, let alone the vault and the path the data takes to get back to the client.

So what happens, the password is entered, the hash sent to the client’s group, the group then requests the account info from the datamanagers for that data then the retrieval from the vault holding the data back to the client will have many hops (sometimes around the physical world) across XOR space. Even if it fails there is plenty of hops client->group->datamanager->group->client (failed attempt)

More like a few hundred mSecs and for us in AU may be nearly a second.

So how many brute force attempts can be made per day?

100mS - ~800,000 per day
200mS - ~400,000 per day
300mS - ~280,000 per day <-- more likely on failed attempt

  • Lets say the minimum of 4 digit pin. That’s an average of 500 tests required unless the obvious of 0000, 1235, 0055 etc are used.
  • Lets say they use a common word (not name) requiring a 1,000 word dictionary for their username (500 average tests)
  • Now lets say that this only occurs for 1 in 10 common passwords.
  • for this analysis we cannot assume the stupidest situations where the the all 3 are obvious values, because that is solved in minutes no matter how you try. Analysis assumes that the pin is at least non-obvious. (Fred-0000 pass fred is not worth analysis since one could just guess it. This is brute force analysis)

That means 500 * 500 * 10 (2,500,00) tests before one can expect a result. A lot more if an actual name is used (10,000 dictionary needed) ==> 25,000,000

So at the expected maximum of 300K tests per day then that is 8 days for the simplest type of account info, just above the guessable ones. And 80 days if a proper name or common word is used

Now, I was under the impression that if this became a problem that a couple of potential methods could be used to reduce the effectiveness of such an attack

  • introduce a delay (which David was OK with) of 1 or more seconds between the time the password is entered and the Group replied with the account information.
  • Introduce a system where if no account then a “dummy” account info is returned. That would be a selection of public content, no coins etc.

The delay would reduce the attempts per day by 10 fold at least to a max of 28,000 per day
The dummy account would reduce the attempts by at least 5 fold assuming that the brute force program had a quick way to identify it was a dummy account, even though it was designed to look real.

So at 50,000 attempts per day (dummy account) the simplest account would be broken in 50 days. And proper name 500 days.

Moral of the story is that this reverse attack is defeated by using a non trivial user name or password and a proper PIN, even if same as bank card pin. And made useless if code includes a delay or dummy account defense


The network is unable to tell time.

1 Like

But it can do delays of small amounts of time.


Great analysis @neo

The only part I think we need to be careful of is defining brute force as something non guessable in order to suggest it doesn’t apply. Good luck guessing Fred in how many? attempts.

I think your analysis identifies what classes of keyword would be unsafe for this attack (which should include all possibilities including “guessable” keywords), and then the measures that could be implemented to protect them from this kind of attack.

Personally I don’t like the idea of a delay to validate a login - but perhaps it can be inserted only for accounts that don’t exist.

I’m not sure how effective a dummy account could be because it would need to be hard to recognise as a dummy account, and therefore plausible but different each time. It is the most interesting idea to me, because if it can be done well it’s a very neat way of handling this.

Anyway, I think we’ve done a good job of clarifying this area and set the scene for thinking about how to harden login and help users choose SAFE credentials! [high five] :smile:


Well if that was implemented then I would expect the name showing when the client log in occurs would be pretty obvious to the person because it is not anything he recognises but to an unknown attacker it is plausible.

There was definitely talk from David that people could have an alt-account with a different PIN so that if they are coerced to reveal their credentials then it would return an account with public files etc. So a plausible account can be shown to the people demanding the details.

I am not suggesting we implement the delay and/or dummy account solution for the reasons you gave.

I think account setup procedure should have a warning about having non-trivial credentials. If the person ignores the warning then there is little we can do.

1 Like

Sure, unless we come up with something better! The reason MaidSafe came up with keyword + pin is I think precisely to “help” users to chose more secure credentials than I’d they were just asked for an account name.

Maybe that’s the best balance between usability and security, but maybe it can still be improved. It’s such a critical point we should not stop thinking about ways to improve it.


Just wanted to bump this now that we have had a chance to muck around with the launcher. ANyone tested this yet?

1 Like

Not sure it will be possible actually. The network will (not yet) give a dummy encrypted packet back to every request. So an attacker will have to try and decrypt as many chunks as s/he gets returned, which will be one per request. That’s will be considerable effort to brute force especially as the password is strengthened by PBKDFII