Live data from Hacker News

Designing a service for password-less temporary access to resources

medium.com

21–24 of 24 posts

Re: Designing a service for password-less temporary access to resources

#21
post #5

6 characters is pretty trivial to brute force. Someone could set up a script to continuously try all combinations and get access to whatever happens to hit a match. You could block an IP after a certain number of failures, but that doesn't protect against a network of various IPs attacking (which attackers often have access to). Adding an artificial delay also wouldn't protect against parallel attacks. A simpler/bett…

Why an IP block instead of a username block

Because then I could block your access with minimal effort.

Re: Designing a service for password-less temporary access to resources

#22
post #5

6 characters is pretty trivial to brute force. Someone could set up a script to continuously try all combinations and get access to whatever happens to hit a match. You could block an IP after a certain number of failures, but that doesn't protect against a network of various IPs attacking (which attackers often have access to). Adding an artificial delay also wouldn't protect against parallel attacks. A simpler/bett…

Why an IP block instead of a username block

Username block is a denial of service against that user.

Re: Designing a service for password-less temporary access to resources

#23

Each shortcode is 6 characters and is case insensitive. That gives us roughly 1.8 billion (1838265625) combinations. That's only 1.8 billion combinations if you only have computers talking privately to other computers. But in the scenario outlined in the article, people will see the URL, so you must filter millions of those combinations. For example, if I come across a recipe for shoo-fly pie, I don't want to forward…

Hashids.org has already solved this issue for the english language.

They don't allow [c, s, f, h, u, i, t] to be placed next to each other and instead move those to be separators.

Re: Designing a service for password-less temporary access to resources

#24
I've wanted to build a similar system for supporting preview of articles on a CMS. Problem is, users may share multiple URLs with a user so a single JWT token in a cookie doesn't suit that flow very well. Each new link followed needs to extend an existing value with additional proofs (and remove old ones?)
Post reply on HN