Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Free, instant, secure, disposable chat rooms built in Go

niltalk.com

Post reply on HN
Print view View original

91–99 of 99 posts

Re: Show HN: Free, instant, secure, disposable chat rooms built in Go

#91

Post by jfindley »

Someone1234 wrote: post #88
jfindley wrote: post #86

Earlier quoted context omitted.

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 36…

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…

> 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.

Re: Show HN: Free, instant, secure, disposable chat rooms built in Go

#92

Post by TheSisb2 »

hurin wrote: post #89
StavrosK wrote: post #71

Earlier quoted context omitted.

The bigger problem is "how do you ensure that the public key the server sent is actually the other user's, and not a MITM?".

Exactly, you have to exchange public-keys via another method - which is also potentially vulnerable.

Use keybase.io

Re: Show HN: Free, instant, secure, disposable chat rooms built in Go

#93

Post by Someone1234 »

jfindley wrote: post #91
Someone1234 wrote: post #88

Earlier quoted context omitted.

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…

> 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 i…

> 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.

Re: Show HN: Free, instant, secure, disposable chat rooms built in Go

#94

Post by zatkin »

addandsubtract wrote: post #57
DanBC wrote: post #42

Have two buttons: "vote to keep open" and "vote to close". Colour them orange and blue. Release it to Reddit. Potential viral hit.

Have one button. Release to Reddit. Potential viral hit.

For anyone who doesn't understand this reference, there is a massive social experiment going on at Reddit: https://www.reddit.com/r/thebutton

Re: Show HN: Free, instant, secure, disposable chat rooms built in Go

#97

Post by c22 »

hurin wrote: post #89
StavrosK wrote: post #71

Earlier quoted context omitted.

The bigger problem is "how do you ensure that the public key the server sent is actually the other user's, and not a MITM?".

Exactly, you have to exchange public-keys via another method - which is also potentially vulnerable.

But all forms of exchange are potentially vulnerable, the point of using multiple channels for authentication is to increase the challenge-space for potential attackers. Indeed the chief benefit of public key encryption is that the key can be exchanged over a multitude of channels and a compromise of just some of them does not jeopardize the entire operation. Perhaps we need more authentication systems where this is made implicit, with trust based on the number of different mediums the key is transferred over (or the number of different third party signers).

Re: Show HN: Free, instant, secure, disposable chat rooms built in Go

#98

Post by jrussbowman »

knadh wrote: post #64
jrussbowman wrote: post #50

I've been killed kicking around the idea of doing something similar, in go, with the domain I own ChatFor.Us JavaScript encryption, as others have mentioned is the thing I see I was planning that's missing from yours. I'm planning on going a different direction with the domain, this functionality for private messaging for a platform set up for chat rooms as well. Right now though I'm investigating a node.js and rethi…

Nice. From my crude and unscientific benchmarks, I've found that Go is able to handle a lot more concurrent WebSocket connections than Node.

I assumed it would. But I'm thinking socket.io would provide better client support and have been looking at meteor as a way to get something built fast. Going Roth a prototype first as I have a lot less time to do this stuff these days. I'm about equally proficient in both go and node which is to say I can stumble my way to a solution with both.

Re: Show HN: Free, instant, secure, disposable chat rooms built in Go

#99

Post by lukeschlather »

new299 wrote: post #79
lukeschlather wrote: post #78

Earlier quoted context omitted.

> That's kind of a shame. It would be nice if apps distributed over the web could be signed the same way they are from repositories. This sounds like a theoretical impossibility. The server's source code is by nature closed, and while the server could provide you a copy of the source with a signature, there's really no way for you to verify that the code you've been promised is the code that is running.

A browser feature would be required that could calculate/display the hash of the delivered code and optionally verify it against a 3rd party server. Ideally you'd want have particular versions signed as "audited" etc. I don't see how it's a theoretical impossibility.

You're neglecting the server-side code. If you have access to the full source code to verify it, you're not describing a web service, you're describing a local application that happens to be implemented in a browser.

You already can distribute signed browser add-ons.

Post reply on HN