It sounds to me like “the desired out come [sic] of a very short URL” needs to be examined: What is so wrong about a long URL? Google use them, and Apple use them. As a content-identifier, a URL should (conceptually) be a hash of its content and accessor, and so very compressed hashes for mostly public information (like on Twtitter) are absolutely acceptable. URLs can get quite large these days, and long URLs may scare people giving them pause before sending them to others. For all these reasons and more, I’d really like to see this point justified further.
However even given that, there’s other strange advice in here as well, like “Do not use obfuscated URLs as a backdoor.” which is silly. A long, hard-to-guess URL is absolutely more secure than a short, easy-to-remember (and frequently-typed) password.
And the proposed protection against timing attacks is troubling in the face of a much simpler solution: Find the max lookup time, and sleep up to it. Add some random fuzz to protect against jitter.
A long, hard-to-guess URL is absolutely more secure than a short, easy-to-remember (and frequently-typed) password.
This is false. The problem is that you’re only considering the raw entropy, but not all of the other technical implications - because a URL is not considered sensitive information, it may be retained by proxies, in access logs, browser history, desktop session data, and so on.
It may be sent over a message bus like DBus, or through custom IPC protocols to other applications on the system. Browser extensions may even send this URL elsewhere for purposes like malware scans, because they don’t expect the URL to essentially contain a password. And so on - the possibilities are endless.
This would be a good moment to invoke this article. Deviating from the assumptions under which something is designed, is generally a bad idea because of pitfalls like this.
a URL is not considered sensitive information,
And you a password is? That’s so cute.
Should I address you? Or the person working the sock puppet?
It may be sent over a message bus like DBus, or through custom IPC protocols to other applications on the system.
That’s no different than any keychain or password manager.
Browser extensions may even send this URL elsewhere for purposes like malware scans
No, they don’t. But it’s not like they’re smart about security, it’s that they’re smart about the privacy backlash. Software that works that way is illegal in Germany and Switzerland, and about to be made illegal (GDPR) in the rest of Europe.
If you know of a browser extension that does this, you should have it reported.
And so on - the possibilities are endless.
No. They’re really not.
Meanwhile, the very real risk of someone having to remember “yet another password” writes it down with all their other passwords – know an attacker knows by searching for that password which file contains all of the other goodies. Yum.
Or someone decides to change the password. Or reuse it. Or copy/paste it and accidentally paste it into the wrong place.
We have too many passwords and I get it: we think we want to “make things secure” instead of authenticating and confirming authorisation to resources. But that’s just caused by too many cargo-cult programmers who find one blog post they agree with and forget how to think for themselves.
It sounds to me like “the desired out come [sic] of a very short URL” needs to be examined: What is so wrong about a long URL?
SMS. You only get 160 characters, and you want as short of a URL as possible. This is the sort of constraint I’ve had to work around for clients in the past.
That depends on whether or not you allow weak passwords.
Do not use sleep to mitigate timing attacks. It might seem tempting, but it doesn’t work. You either use too short of a delay (and your random fuzz becomes useless with enough samples) or too long of a delay (and expose your server to easier DoS attacks). A Goldilocks strategy won’t work either: the goalposts will move over time, and you’ll need to figure out where/how to calibrate the values for the delays. You’re better off solving the real problem.
160 characters is plenty for authenticated secret-key encryption.
Do not use sleep to mitigate timing attacks.
Yes, do. And in fact read the article you just linked to where it suggests exactly my mitigation suggestion: “Make the operation take a minimum time (clamping)”. It suggests a weaknesses to local users and some handwaving about security by obscurity, but no real actual problems with it.
[too long of a delay] and expose your server to easier DoS attacks
Saying “easier” is intellectually dishonest. If someone can DoS your cpu idle, then they can certainly DoS you when your cpu is warm. Process and network utilisation remains almost exactly the same, and in all practical ways of measuring it, you’re introducing no new attacks.
The weak password is the one that someone has to write down in an accessible place, but by all means: put your money where your mouth is and find my secret url.
Just stop using passwords.
Yes, but not “a custom message + the URL”, which is what my past clients wanted.
The DoS comes in when you have idle connections being used (and using memory) for needlessly long periods of time, which allows an attacker to send more requests than the server can fulfill which blocks legitimate traffic.
Having a long sleep on the server side makes that easier.
I wouldn’t be so quick to call something intellectually dishonest, because all that does is hamper understanding and make future interactions needlessly adversarial.
Two messages are cheap.
Anyway, I try to avoid making things harder for myself since I’m trying to save my customers their money.
for needlessly long periods of time, … I wouldn’t be so quick to call something intellectually dishonest, because all that does is hamper understanding and make future interactions needlessly adversarial.
You keep saying “long”. Be specific. Give timings: This is usec and nsec territory. An attacker that can overload you taking T+100 usec but not T usec doesn’t exist.
If you generate 9 raw bytes from a cryptographically secure pseudorandom number generator, then base64 the result, you will end up with a 12 character identifier (72 bits of possible values).
If you generate 9 raw bytes and base64 the result, the number of possible values is not increased by running base64 (although the prose could be read to implies it would).
Furthermore, this record is completely randomly generated and has nothing to do with the rest of the data stored in your database. There is no pattern to be found. (The closest relevant buzz-word here is a “zero knowledge”.)
The closest relevant buzz-word should be “Message Authorization Code”, because that’s how you would do this securely. It would also make the timing attack a non-issue.
Zero knowledge encryption has nothing to do with this (and I’ll resist the urge to make the oh-so-tempting pun about the author because it’s entirely unfair).
The 9 bytes offer 2^72 possibilities. The base64 transformation is just for safe storage.
Did you mean “Message Authentication Code”? Or am I missing one of the linguistic atrocities from bizdev?
Zero knowledge isn’t encryption, it’s authentication. :)
I assume you mean “so it’s valid in a URL param” (which IMO is worth mentioning given the intended audience)
I did mean “Message Authentication Code”, yes. There’s no reason to allow clients to tamper with these.