81–90 of 249 posts
Earlier quoted context omitted.
> Your data is in the clear within Cloudflare Just a heads up you're telling Cloudflare's CTO how Cloudflare works
Just a heads up - it's the inventor of Nagle algorithm telling Cloudflare's CTO how Cloudflare works. This could be very interesting ;) (also stuff like that happens quite a lot on HN, I recommend using some user tagger extension)
Yeah that would be super useful, so far I've been going by remembering usernames
Come on man, 4 submissions in 5 days all leading to your startup's website? And a profile created 5 days ago with zero comments on anything you didn't post? You could at least try to make it look like you're doing more than promoting your startup.
Not trying to hide the company, in fact pretty proud of it and the new things we're doing. But we are very early stage and still in beta.
I do want to add value through the posts and discussion like this regardless.
Come on man, 4 submissions in 5 days all leading to your startup's website? And a profile created 5 days ago with zero comments on anything you didn't post? You could at least try to make it look like you're doing more than promoting your startup.
If this character is coming up with worthy content then who cares? The vast majority of blog posting is indirect (or direct) marketing.
I don't think he's done anything wrong.
Earlier quoted context omitted.
If the hacker gets access to the database due to a network config error, then they will be able to query the database, but only get records with some sensitive fields encrypted. Given the number of email addresses that have been hacked and stolen (3.75 billion in Troy Hunt's haveibeenpwned alone), I believe doing one little extra bit of encryption on email addresses is worthwhile. We push that into our ORM layer and…
Wait, so you encrypt the user's email before it's inserted into the table? Are you using a different field for 'username' on logins, or do you have to jump through some hoops to find an encrypted email to do a login check against the pw hash?
Earlier quoted context omitted.
Wait, so you encrypt the user's email before it's inserted into the table? Are you using a different field for 'username' on logins, or do you have to jump through some hoops to find an encrypted email to do a login check against the pw hash?
Can't you encrypt the entered email and search with that?
For the User.email field, we crypt/decrypt in the ORM/DB layer. So we search with the encrypted value that is stored in the db. App code provides plain-text email, ORM encrypts and searches with that value. Symmetric encryption of short strings is pretty fast and this is not a high volume API.
We use rate limiting on the API to protect against DOS on this API.
Earlier quoted context omitted.
Can't you encrypt the entered email and search with that?
Password hashes are handled separately using bcrypt - another story. For the User.email field, we crypt/decrypt in the ORM/DB layer. So we search with the encrypted value that is stored in the db. App code provides plain-text email, ORM encrypts and searches with that value. Symmetric encryption of short strings is pretty fast and this is not a high volume API. We use rate limiting on the API to protect against DOS o…
Earlier quoted context omitted.
Password hashes are handled separately using bcrypt - another story. For the User.email field, we crypt/decrypt in the ORM/DB layer. So we search with the encrypted value that is stored in the db. App code provides plain-text email, ORM encrypts and searches with that value. Symmetric encryption of short strings is pretty fast and this is not a high volume API. We use rate limiting on the API to protect against DOS o…
If it's symmetric, then doesn't an app vulnerability make it possible for you to leak your key? Then the app also contains access credentials to the DB, so vulnerabilities in the app will still lead to real access to the DB, right?
Earlier quoted context omitted.
Because when you handle a request, you need either respond to it or close it. If you don't close it (e.g: res.end, res.send, ...) the connection remains open. Also all the memory allocated for that request stays around without being collected.
Agree with the point, but remember normal HTTP/1.1 /2 keep alive should close that connection in 15-30 seconds for all modern browsers. It will give rise to a DOS vulnerability as you point out.
Usually error events propagate through piped streams, but that largely depends on the order in which the event handlers were defined.
Isn't best practice when it comes to passwords to actually choose a good one, use a password safe, and _not_ rotate?
Choose good passwords, long, special chars, preferably random and generated by a password generator / manager. And then change periodically. That period depends on your application.
We change our cloud passwords and keys every 90 days.