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:
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
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
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
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.
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] 
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.
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?
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