Also, let's not forget another point, is that CD Projekt was already a large distributor/localizer in Poland long before they had their RED division: https://en.wikipedia.org/wiki/CD_Projekt
So they didn't really start out of nothing when it comes to having connections with game developers.
The problem with taking a discussion from a public forum private, is that in the current state, everyone can choose to dispose of the room.
As proven in this very thread, it doesn't really work. The idea that everyone can dispose of the room is interesting, but there probably should be an option so that only the creator (or the first to join) can dispose of the room, for such public place cases.
It's actually meant for small group of people to have private conversations and is not really ideal for take a huge public discussion private. The idea of marking a peer the creator or making the first peer an owner complicates the whole privacy and security aspect.
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.
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.
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.
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.
> 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.
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.
Disposing of the room does remove it and kick everyone out, indeed. And then the link is invalid. Neat. According for the privacy page, it's all living in RAM only, so in theory there is no logging (https://niltalk.com/pages/privacy). Guess we can check the code and see for ourselves, of course.
It doesn't need to be trust-based, and in fact shouldn't be trust-based, because even if I trust you, I also have to trust the people who could coerce or bypass you, or people who could maliciously access/modify your systems.
This is why end-to-end encryption is really the only way to make promises as a server about not reading / storing logs.
The dispose button is far too inviting where it is. I started to click it thinking it was the submit button till I read the text. Perhaps put it somewhere top right or someplace other than right beside the input box, also, it's kind of weird that there is no admin for the forum, so any participant can delete it I assume?
Yes, that's by design. These rooms are meant to be completely ephemeral and private amongst small groups of peers. It's critical to ensure that anyone who is connected is able to quickly dispose of the room for security / privacy reasons. Once a room is created, there is no "admin" or "host" per se, just a short lived private space.
It's critical to ensure that anyone who is connected is able to quickly dispose of the room for security / privacy reasons.
And if you're not a small number of trusted participants (e.g. anon participants, not all of whom you trust, or enough people that one might make a mistake or delete before everyone is ready), that's not going to work. See the example forums being created and deleted above. They could easily allow two passwords on setup though to avoid this - one for admins, one for posters.
On the button placement, it really would be better elsewhere - it is not related to the text submission entry, so it belongs at top somewhere, along with the sound, which again is a forum-level setting.
For me, with Pocket, it's usually two clicks, and typing a tag or two in between. Or one click when I just want to "read later" without bothering with organizing.
The problem is that by the time you reached the functionality of Opera with extensions, your browser is bloated and takes ages to load, and a large chunk of RAM.
I’d have agreed with you just a year ago, but not anymore. Firefox made TONS of performance improvements and Opera actually got significantly worse at memory consumption.
At the end of the day, Aurora (with several addons) is usually below or around 300MB with my normal daily use, whereas Opera Next can easily go beyond 1GB of virtual memory.
In Q3, it was more the way jumping impacted your movement speed which was a discovery. Another example would be the Tribes series, with skiing which was also an abuse of the game physics (and taken as the main movement mechanic in the latest game, Tribes Ascend).
It's nice to see such parts of gameplay emerging from simple bugs. I would argue that it's much more rare nowadays, with games which aim to be always more realistic, and blocking your movement.
> In Q3, it was more the way jumping impacted your movement speed which was a discovery.
Not really sure what you're talking about. Rockets and grenades hugely impacted player speed in Quake 1, but not so much in Quake 3. Check the speed run of the following level to see what I mean:
It was quite serendipitous how although Rocket jumping was "incidental" to Q1 most levels still played extremely well using that feature. Still level-designers who later knew about it and designed for it managed to (ab)use it even more. I designed a level where the entire layout was optimized around rocket-jumping being possible (and encouraged) as much as humanely possible, great fun!
So they didn't really start out of nothing when it comes to having connections with game developers.