5 ms·
Love these kind of ideas. Reminded me of once I was trying to allow access to a file with a password. It wasn't any super-secret file or anything, just a CV of
by can16358p 4y ago
Love these kind of ideas. Reminded me of once I was trying to allow access to a file with a password. It wasn't any super-secret file or anything, just a CV of a friend hosted on a static file server and she wanted it to "protect" it with a simple password (just didn't want it to be directly available to anyone viewing the homepage. No mission-critical secret of any kind otherwise).
Having no real/strict security requirements and being lazy to go server-side scripting, I simply hashed the password. Noted the hash. Saved the file into a folder like "/${hash}/Proper Name.pdf". Hashed the hash again and embedded it into client-side JS. Wrote a JS function that took the input, hashed it twice, and if second hash of the entered password matches that, download the file "/${first hash}/Proper Name.pdf".
It worked like a charm, but please note that this is prone to attacks so if anyone reading this thinks it's a good idea to implement actual security, DO NOT. It is not. Fun to play with though.
- jesprenj 4y agoWhat attacks?
- martin-adams 4y agoMaybe the browser or an extension leaking the URL of the file, which could ultimately get indexed in a search engine.
- jesprenj 4y agoFair point, though search engines are aware of special headers that tell them not to publicize the link to the content. Would it be any safer with the key in the GET parameter string? Search engines still usually treat this string as part of the address.
- Godel_unicode 4y agoAmong other things, it’s almost certainly the case that the web server isn’t implementing a constant-time string comparison for the URL, which enables you to brute-force the value one character at a time.
- jesprenj 4y agoWoah, that sounds interesting, do you have any links to share regarding that issue?