171–180 of 193 posts
More general: Things to never build yourself: Things outside your core business. Are you selling a notification service? Build it yourself, otherwise find either self-hosted or hosted solutions, depending on situation.
Earlier quoted context omitted.
> It is really not difficult to use BCrypt Something I once saw in production: An otherwise normal usage of bcrypt, that "prehashed" the password with sha512 before passing the resulting hash to bcrypt. This is conceptually reasonable (although not very useful) for reasons I don't think are worth going into, but had two critical problems. 1. It technically broke bcrypt's side-channel protection against timing attacks…
What's been interesting to me is that during tech interviews, we eagerly have applicants roll their own sorting, or searching, or caching. But you never have questions about crypto or auth. Why one and not the other? Are both not critical to get right? And then I'm reminded of the bug that was hidden in plain sight for 20 years in Programming Pearls [1] in their implementation of a binary search. This same algorithm…
Earlier quoted context omitted.
He mentioned transparent migration and the problems encountered with it.
> Auth providers cant help you because the passwords are hashed... You need the same algo or you cant authenticate using the data they have. Seeing as you have that it becomes a non-issue
Earlier quoted context omitted.
There is a whole line of thought that accounts should be passwordless and accessed via an email reset link as part of normal login procedure.
Which is great until you lose access to your email.
Earlier quoted context omitted.
Your point 1 seems wrong. SHA-512 is constant time for any reasonable password length and any reasonable implementation. It hashes 1024-bit blocks in constant time, as it only uses 64-bit word operations such as add, shift, xor etc in a fixed order with fixed constants. There are no input data-dependent lookups, or other variable-time operations. If you are considering the string copy that happens when the unhashed p…
> Your point 1 seems wrong. SHA-512 is constant time for any reasonable password length and any reasonable implementation. I'm aware of this, and it's why there's a "technically" in my original point. Of course in practice it makes no difference, and I consider the better use of bcrypt's input space when prehashing to outweigh leaking a pretty useless amount of side-channel information for extraordinarily long passwo…
If you find collision space reduction interesting, then you might find it even more interesting that truncating SHA-512 makes it more secure not less.
This (and the higher rounds safety margin) is why I choose truncated SHA-512 over SHA-256 for this sort of application, even though the number of output bits is the same:
Check out the red boxes on https://en.wikipedia.org/wiki/Template:Comparison_of_SHA_fun...
Earlier quoted context omitted.
There is a whole line of thought that accounts should be passwordless and accessed via an email reset link as part of normal login procedure.
Yeah I hate that method. It's good in theory but terrible for the user. I go to a website I want to use. I click the magic link. The email takes 10 seconds to show up. In that 10 seconds I find something else to do while I'm waiting. I get distracted and find the magic link in my email 10 minutes later. It's now expired and I have to start over. Or just give up. With a password, I click the site I want to use, my pas…
Even longer if you have greylisting turned on, it gets temporarily rejected which means you then have to wait N minutes before it gets accepted (assuming they retry sensibly and don't just spam retries every 2 minutes and get fail2ban'd.)
By which time it might well have timed out anyway...
Earlier quoted context omitted.
> Auth providers cant help you because the passwords are hashed... You need the same algo or you cant authenticate using the data they have. Seeing as you have that it becomes a non-issue
Perhaps I'm incorrectly assuming auth providers don't expose an API for exporting all that data. Such an API would seem to be a fairly attractive attack vector.
Earlier quoted context omitted.
> notifications for my apps What kind of notifications are we talking about where you can get away with self-hosting? AFAIK, Push Notifications on smartphones have to go through Google and Apple's servers. Maybe if you're doing email notifications?
I think there are a lot of 3rd party wrapper around Google & Apples Push APIs, which are not really needed. You can send Push Notification yourself just fine. For email though, not sure, that's a completely different topic. It comes with many headaches, using a service like SendGrid or Mailchimp seems like a good idea, and if you really want to roll our own mail servers down the line you can still do that.
For email we run bsd (not that that matters, it is just a factoid) servers, correctly configured which seem to work well (mail does not get to spam unless it is).