Open alist opened 10 years ago
I think a range of 6chars with [a-zA-Z0-9] is fine. We could add some relatively URI-friendly special chars such as "-", "~" and "" to it.
I was a little concerned about the method. I could be wrong, but I think we use substring(hash, 5)
which would disturb the distribution across that range.
I suggest generating case-sensitive `[a-zA-Z0-9-~]` char paths. Case-sensetivity could theoretically produce overlaps (aL1nK vs. Al1Nk) but it increases the entropy significantly.
Because the length is short, it's convenient for adding to SMSs. Because length is short, it can be guessed. It's a trade-off, and given that the short URI is the only way for some users to gain access to their request, I think it's worth it.
Worst case scenario, if a short URI is discovered/guessed: We don't expose any user-critical data in the response (email, telephone no.). Also, advice requests being disparate, if multiple advice requests are somehow discovered, there's very less chance of finding a link between any two to trace the activity of one single user. To a man-in-the-middle, it's appears as disparate request-response pairs without any significant value.
Specifically for protection against hack attempts, we could track the no. of failed lookups on accessing /x/*
and block the IP if it fails past a large threshold (or set a backoff time for the IP).
I like how you analyze the pair's value as a target.. I also can't really see humongous value in guessing these shortURLS.
But from my experience behind nats and seeing the force of botnets, blocking IPs really isn't effective.
10 billion combinations still aint bad at 68^5, but it don't make me sleep easy. I suppose what you're saying is short urls is not a cryptographically hidden space no matter what, and at least 5 chars is the size of short term memory?
Howwould you implement char paths?? Here was the original shorturl, if you'd like to contribute https://github.com/alist/shorturl :-)
Yup. ShortURLs are not cryptographically safe because they're short. But their short length is what makes them usable.
You're right - IP-blocking isn't going to cover botnets trying to bruteforce a shortURL. But if botnets do target the platform, we'll have bigger issues to worry about. It's going to slow down everything. We'll need to have some sort of bot detection/request-throttling-per-IP mechanism, similar to what Twitter does for their feeds.
I'm in favour of having at least 6 chars - for usability and also for the same reason most web services require passwords to be at least 6 chars. Google uses minlength of 8.
I think we can monitor the rate of usage and then take a call. We can always increase the length later and everything will still work fine. Hypothetically, if we release now and we increase the length to 8 a month later, all existing 6-char paths would still be secure (because the address space is relatively empty).
Will take a look. :)
This is to be used when sent to mobile devices, but I don't feel it's a large enough search space against attackers-
I think 66^ 8 of entropy would be better -- 40.9319 terrabytes https://www.google.com/search?q=66%5E8+bits+
Shirish do you have thoughts on this?