Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<blockquote> <p>Or is this lockout mechanism just stupid and annoying for users without providing any significant protection?</p> </blockquote> <p>You've <em>potentially</em> hit the nail on the head there: Security through obscurity is not security.</p> <p>Instead of trying to "discourage brute-force guessing", use URLs that are actually hard to guess: the obvious example is using a cryptographically secure RNG to generate the "random 20 character string". If you use base64url (or a similar URL-safe base64) you get 64^20 = 2^6^20 = 2^120 bits. Not quite 128 (or 160 or 256) bits, so you can make it longer if you want, but also note that the expected bandwidth cost of a correct guess is going to be enormous, so you don't really have to worry until your bandwidth bill becomes huge.</p> <p>There are some additional ways you might want to protect the links:</p> <ul> <li>Use HTTPS to reduce the potential for eavesdropping (they'll still be unencrypted between SMTP servers, if you e-mail the links)</li> <li>Don't link to anything, or if you do, link through a HTTPS redirect (last I checked, many web browsers will still send a <code>Referer:</code>, leaking the "secure" URL you were looking at previously). An alternative is to have the initial load set an unguessable <code>secure</code> session cookie and redirect to a new URL which is only valid for that session cookie.</li> </ul> <p>Alternatively, you can alter the "lockout" to still work without compromising usability:</p> <ul> <li>Serve only after a delay. Every time you serve a document or HTTP 404, increase the delay for that IP. There's probably an easy algorithm to asymptotically approach a rate limit but be more "forgiving" for the first few requests.</li> <li>For each IP address, only allow one request at a time. When you receive a request, return HTTP 5xx on any existing requests (I forget which one is "server load too high").</li> </ul> <p>Even if the initial delays are exponentially increasing (i.e. 1s, 2s, 4s), the "current" delay isn't going to be much greater than the time taken to type in the whole URL. If it takes you 10 seconds to type in a random URL, then another 16 seconds to wait for it to load isn't too bad.</p> <p>Keep in mind that someone who wants to get around your IP-based rate limiting can just rent a (fraction of the bandwidth of a) botnet.</p> <hr> <p>Incidentally, I'm (only slightly) surprised by the view from an Unnamed Australian Software Company that low-entropy randomly-generated passwords are not a problem, because there should be a CAPTCHA in your login system. Funny, since some of those passwords are server-to-server.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload