[jfindley]

The number of bcrypt rounds is extremely low, too[1]. While the Go bcrypt lib will actually accept a cost of 5, that seems an unreasonably low value to me.

Coupled with absolutely no encryption of the messages in memory, I think "anonymous" would be a better term than "secure" for this.

1:https://github.com/goniltalk/niltalk/blob/master/api.go#L75

[Someone1234]

Your bcrypt complaint is pretty petty. They aren't storing the hash on disk at all, and the chat rooms are only temporary.

I do have privacy concerns about this and agree they can eavesdrop if they wish. Increasing the bcrypt rounds from 5 to 15 would in no way help with any of that.

[jfindley]

It's in a redis database, so it's not all that hard to get at, either, should someone compromise the system. "Not on disk" stops being such a good defence when it's stored in a semi-persistent DB.

My main complaint, though, is that there's simply no reason to choose such a low number of rounds. Using the exact same code as in this app, 5 rounds takes 3551534 ns/op, 10 rounds takes 3583632 ns/op and 15 rounds takes 3623005 ns/op. In other words, it's only 2% slower to use 15 rounds than it is 5, and the default (10) is less than 1% slower.

[Someone1234]

If someone has an active compromise on a running machine, they can intercept network traffic and bypass bcrypt completely.

> In other words, it's only 2% slower to use 15 rounds than it is 5, and the default (10) is less than 1% slower.

So are you arguing that your complaint is petty or isn't? Because this isn't helping your case.

Overall your attack scenario is where an attacker has just enough access to the machine to read memory in the redis database, but not enough access to read memory in the web-server, or at the point before bcrypt has been run in the process.

If redis was stored to disk you may have a valid point. As it stands your argument actually doesn't make sense. If they can access Redis they can access pre-bcrypt passwords and therefore making bcrypt's rounds completely unimportant.

[jfindley]

> If they can access Redis they can access pre-bcrypt passwords and therefore making bcrypt's rounds completely unimportant.

No. The unhashed passwords are not stored in redis. What I think you're missing is that there's a significant difficulty gap between connecting to, and reading data from, redis compared to gaining root access and reading arbitrary memory on the server.

> So are you arguing that your complaint is petty or isn't? Because this isn't helping your case.

You make a good point - even if it's not the one you were trying to make - and that it's that my benchmark was not particularly helpful as it measured per operation, not per hash.

You missed the point I was really trying to make, though, which is that difference between 5 rounds and 15 (your choice, not mine - I probably wouldn't choose 15) isn't that significant when you're doing legitimate stuff, like hashing chatroom passwords. It is significant if you're brute-forcing.

[Someone1234]

> The unhashed passwords are not stored in redis.

Never claimed otherwise. They are stored in memory though. They're in the web-server process, and the process which actually conducts the bcrypt hashing.

> What I think you're missing is that there's a significant difficulty gap between connecting to, and reading data from, redis compared to gaining root access and reading arbitrary memory on the server.

You don't need to read arbitrary memory on the server, you only need to be in the same scope as the web app runs in.

> It is significant if you're brute-forcing.

If you're in a position to steal the bcrypt-ed passwords in this case, you're in a position to steal the plain text passwords (both in memory, both in the same scope, why waste time breaking bcrypt?).

If the author altered the code so it DID store on the file system medium to long term, sure, it might be worth while increasing bcrypt's rounds. In the mean time bcrypt is almost pointless in this case as plain text exists in the same execution scope and is accessible to processes with access to Redis.