Invitation to brute-force?

Product Discussions
1

When I use several passphrases for different users for one bucket, it seems that the users can easily spot that there might be more files in a bucket than a user has access to with his assigned passphrase.
They can check the number of files in a bucket and compare with the number of files they are seeing.
In theory then they could start brute-forcing passwords to gain access to other files.

I am wondering, if it would make sense to add some kind of brute force prevention like max number of retries or add some steadily increasing waiting time after each password attempt?

3 Likes
2

Brute force couldn’t be prevented because everything is e2e encrypted. Especially if shared gateways are not used.

All encryption happens on your local node, and you can try to brute-force it.

However our key derivation process is very resource consuming. (see illustrated/encrypted-keys.svg at d59f54d782e0cdfbf939376ac0a96281594a2f03 · storj/illustrated · GitHub and illustrated/encrypted-path.svg at d59f54d782e0cdfbf939376ac0a96281594a2f03 · storj/illustrated · GitHub) and we use modern encryption practices which are safe against brute force attacks.

BTW, block chains are in similar situation. Everything is public, but there is no chance to brute-force the hashes/keys.

So if you happen to have an alien technology, which can break SHA quicker then billions of years, I would recommend to get some money from the Ethereum chain instead of decrypting Storj data ;-D

8 Likes
3

@elek is quite right, and explained it well. I do want to add, though, in case it’s not clear, that it’s still possible to brute-force a weak encryption passphrase. We make it as difficult as we feasibly can, but if someone already has access to your bucket and your encryption passphrase is, for example, a single English word, there’s not much we can do.

7 Likes
4

That’s exactly what I mean and my concern.
So once somebody gains access to an account, he has literally unlimited attempts to brute-force or guess an encryption password, without the account holder even being notified that somebody is currently trying to hack the account data.

Several things would be really helpful (again, I don’t know what technically is possible):

  1. Show in dashboard when was last login and from which IP
  2. Let me restrict access to satellite dashboard to specific IPs and to deny the rest (for example Tor exit nodes)
  3. Rate limit the number of password attempts, meaning to add increasing waiting time between attempts
  4. Enforce strong encryption passwords. Currently it seems that passphrases with as little as 1 character are possible to use.
5

This is about logging to the satellite web UI, not about the encryption. As we discussed, that can be done offline. It might help if the attacked can get access to your web password (but not the encryption key).

But at that time, the attacker already have the encrypted data to crack it offline…

That’s technically possible, but not all requests use the dashboard. You can use only API.

Also: checking a database if IP addresses for each request is less performant.

If you afraid about malicious login, it’s not a brute-force crypto problem any more, but good old password based authentication.

Again, this can be done for UI, but not for file encryption, which can be tried offline.

It can be done on UI, but when you just use API, it’s not possible to know how strong was the original password (because the e2e encryption).

So it’s not easy. I think the best thing is what @thepaul recommended: use strong encryption key.

6

Also, if you want stricter separation of access rights, you can just use separate buckets.

But yeah, there’s a reason storj encourages the use of the automatically generated long passphrases. You won’t see those brute forced any time soon.

2 Likes