Show HN: Password-protect a static HTML page
robinmoisson.github.io
robinmoisson.github.io
1. Concatenate the username and password, hash the combination
2. Name the HTML file with the grades using that hash
3. When the user logs in, calculate the hash in Javascript and redirect to that HTML page.
In theory, you can only work out the URL of the page if you have the username and password in hand. I'm sure it was pretty trivially bruteforcable, but aside from that it seemed sort of okay.
Until I realized that directory listings were turned on, and the directory that had all the HTML files sometimes had no index.html, thereby rendering the entire obfuscation scheme moot.
(n.b. I was too ethical to use this to peek at anyone's grades! I did try to report it but it was never clear to whom to report it to, and since every teacher generated these files using their own copy of the program, there was no obvious central place to report this to. A couple of years later online grades were centralized into a different system)
I logged off my account, and then just for the fun of it, decided to log back in using my course unit (INF180) as the username and password.
Lo and behold, It let me in. As the course administrator. I could see student records and past assignment gradings for everyone else on my course.
Looking at the folders, it seemed that future assignments etc. were also stored within that account. I didn't go any further. I simply logged out and stayed quiet (and uneasy) about the whole thing. I was too scared to report it in case I was thrown off the course for 'hacking' the system.
A few years later (after I had well completed my studies), I was helping a friend in the same labs with an assignment. I wondered if they still had the same flaw, so I found a spare workstation and tried the same trick, but it wouldn't let me in. Glad they fixed that loophole.
In hindsight, I probably wasn't the only one who might have cottoned on to this. It was purely due to lazy systems administrators. All students were given their student number as their login, and the default password was.... our student number. It was strongly suggested that we change our password after first login, but it was never forced upon us, so not many did change it.
On that lazy day, I simply wondered if the same password 'policy' was in place for our lecturers too, so I guessed that their login might be the unit code, and the password would be the same. In a class full of bright CS wannabes, I am sure a few of the others had the same thought.
No doubt they became aware of this at some stage and that is why it was (thankfully) changed.
Since when have this country's schools been run by idiots? Not you, but the people who would have let such an idiotic situation come about and on top of it, have created a climate where one would fear repercussions for reporting on it? Since when has this country become run by uncomprehending idiot authoritarians? When did this come about!? AFAIK, High schools and colleges weren't like this in the 80's.
I think the entire university's IT department at the time consisted of 4 guys running around trying to keep the mainframe running. There probably weren't any solid policies on password security.
[1] Much like the Phone Cops [2], the Net Cops could have cut my career short.
[2] Those Boys From Bell. Also, https://www.youtube.com/watch?v=cTPzTG1Lx60
On the other hand, the new Dean of the computing faculty that took over the year after was a really cool guy, and he is someone I wouldn't have had any hesitation to go to and report such incidents.
In retrospect I dodged a huge bullet!
Of course, we either found them during tech class (pre-req for A+ class) or after we'd asked the school tech for permission to explore (and been told it was okay as long as we documented what we learned/didn't do obviously malicious things).
I think the worst I saw was a kid get suspended for a week then kicked off the network for the rest of the year. He got caught with a ton of warez, pirated stuff, etc on his share when we got investigated by the district for accidentally taking down the network because someone left Guild Wars auto-patching on.
Good times.
You could see other people's grades by knowing their username.
I emailed the professor. He thought I was being insolent.
For all I know the system is still like that.
---
My favorite though was the queuing system to pass off CS lab assignments. A bit of XSS, and your name made its way to the top.
So if you change your password, you cannot access your grades? How is this okay?
Of course, each set of grades is managed by each teacher individually, so you would have to individually update your password on each "system"...
Doesn't seem very secure to include external JS on an encrypted page.
Why not include those things inline?
And why does it need jQuery for a simple 1-input form field that decrypts a string?!
https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
It looks like the developer for this page copied the CDNJS links at some point but didn't do so consistently and later commented out the SRI portion of the jQuery tag:
<!--integrity="sha256-hwg4gsxgFZhOsEEamdOYGBf13FyQuiTwlAQgxVSNgt4="-->I'll probably look into adding Subressource Integrity checks for the other two as well.
Priceless.
But I understand your point, plus it would be nice to have a page working completely offline. Will add the option to embed the needed library in the single file.
It definitely does not need jQuery :) The page was a POC, since it seems it might be useful to some I'll clean it up. Thanks for the feedback !
[Edit: looks like this may already be on the way to addressing your issue https://github.com/robinmoisson/staticrypt/issues/1]
Why do people like to complain so much?
Disregard my comment.
Most of them just focused on obfuscating the password in the source (most by encoding, the fancy ones through some opaque evals), but I came across one during that time that claimed to use AES and even had a not-insignificant cash prize for defeating it.
I really wish I could find that site... would be fun to give a shot at cracking it given what I know now.
Anywho, in my search for that site, I found a pretty good tutorial considering it's age (1997!) on implementing DES in javascript to achieve something similar[0].
Edit: redacted the name of company.
Here are the similarities I saw:
- Payload is encrypted client-side by the sender
- Encrypted payload is decrypted client-side by the receiver
- 3rd party provides the unlock passphrase
I think I'd much prefer standard AES to AES sprinkled with a bit of proprietary magic, as the latter is more likely to introduce new attack vectors than not.
My input doesn't seem to matter, but I used:
<html><body>Hello</body></html>
Password: abcdefg
<head> is truncated.
Firefox was escaping the downloaded data (loaded in a href attribute) differently than chrome, that problem should be solved now. Do let me know if you still experience issues.
They had found some library that would take a password and a desired output and would generate some super crazy javascript looping/shifting/replacement algorithm that would generate the name of the html page that had the desired content. The report was available openly to the internet, but there were no links to it, just through this algorithm.
I spent about 4-5 hours slowly but surely reverse engineering the algorithm so I could figure out what the page name was. There was an immense sense of satisfaction that came with being able to look at those reports.
What I like about my implementation is that it has a tamper proof clear text message included with the encrypted payload. And everything (images and JS) is inline, so nothing external needed.
And weak password are subject to bruteforcing.
If you trust the server, rather use htaccess. Or place the document at example.com/mySecretPassword/index.html Just be careful about outgoing links.
http://www.acme.com/software/securepage/
(2010 or earlier, basically does similar trick, from the authors of thttpd, mini_httpd and micro_httpd!)
Edit: For this something like tweetnacl is probably more foolproof, checkout: https://github.com/dchest/tweetnacl-js
Or libsodium which can also be compiled to pure js: https://github.com/jedisct1/libsodium.js
Another easy to make error would've been to use the same key for the MAC and the encryption. In this case, the library probably uses a unique salt everytime it generate a key from the passphrase, so you're fine there too.
In principle though, using a library like NaCL or Libsodium offers a high level "encrypt and sign" primitive and you should be using something like that to avoid getting anything wrong. There are lots of mistakes to be made.
libsodium is unfortunately a bit broken because the pw_hash functions (argon + scrypt) don't work in the browser.
How could you use AES with a passphrase with no key derivation function?
Similar, but uses files instead of HTML text.
But you can still control access to the content, distributing the password by other channels.
A plausible use case for this (... like basically any crypto thing) would be clandestine organizing. Significantly less sophistication required, and much less of a trail left, to put a static site online.
Shit, you wouldn't even need to host it as a site: you could drop it somewhere as text, eg on a pastebin or in a forum comment, with "save as .html and open" instructions. And you could distribute the encryptor itself the same way.
The really great thing about this is that you could do practical human crypto, without Alice or Bob needing any special knowledge or equipment besides a web browser, using arbitrary uncontrolled public infrastructure.
... though if someone knows the password + controls the infrastructure you've used, they could substitute their own content.
... also short password + direct access to ciphertext -> easy brute force.
... also everything here: https://news.ycombinator.com/item?id=14554187
Wouldn't use it for anything state-level or life-or death. There are mitigations, but that would increase the difficulty and necessary sophistication for using it. Actually, this probably falls into the uncanny valley where it seems just accessibly cyberpunk enough to be extremely dangerous to anyone relying on it. But still, really cool IMO.
[video demo](https://youtu.be/zevMEiR2CZY)
Also, as a non-security person, just how secure is this? Like is it used more for "eh, I don't really want something to see this, but it's not the end of the world if they do" or more like "yeah, use this for extremely secure content, it's safe."
The encryption itself is solid (assuming it is implemented correctly and as described, I've not inspected the code) but as mentioned a short pass phrase combined with predictable plain text format would make this quite easy to brute force.
Also, you can't revoke access (again, without site-wide re-encryption).
An interesting POC, but not something that is really practical for broader use.
Even when you manage to keep the key secret I can't revoke your access to the material or prevent you re-transmitting it to others.
It's a hard problem, and this is certainly a novel solution to that problem, but I still don't really see myself using it.
/s
My guess is it's about as secure as putting an encrypted file on the internet. Except this has almost all the information you need to know how it was encrypted. Plus it has a useful guess-the-password form. There is no attempt-limiting or rate-limiting if you can download the file.
It's probably good enough for stuff like an informational product that you want to put behind a password but not good enough for storing your credit card details.
longer answer: look at the last script tag in the demo page, it exposes the encrypted HMAC string, the encrypted HTML text, the encryption method and even the library used to decrypt. You can easily brute force the passphrase
...or better yet embed some code in a popular web page and have the netizens brute force it for you (distributed computing).
In general, client side obfuscation is difficult to perform securely as it shares too much information to be secure.
It's not something I'd use for serious security applications, but fun for interactive fiction.
XTEA is not a military grade algo (but there's only been a partial attack on reduced rounds). All in all the overhead can come in under 2KB in all.
I don't think it's a scheme that's even relevant to this context, though.
Edit: source. https://en.wikipedia.org/wiki/Rubberhose_(file_system)
If the encryptor offers multiple inputs, one a dummy "sure, here is my password, officer" HTML and passphrase, the other the sensitive one this scheme could work. Hiding both in a single blob, plus some noise, could work in the browser too. Seems it might offer some degree of plausible deniability. Some investigation of the decrypted dummy HTML might reveal it isn't large enough to account for the size of the blob. This doesn't seem like an insurmountable obstacle though. If the tool hides an arbitrary number of inputs in blobs that are indistinguishable you'd seem to have a great deal of deniability.
Edit: of course, sucks for the suspect if the interrogator doesn't consider their life valuable.
For those not familiar with the terminology, "rubber hose" in a cryptography context is a euphemism for torture. I know of two approaches to counter it.
Plausible deniability, where you can give out a password that unlocks some of the data, but your adversary has no way of knowing whether that's all of it. Useful if you can expect that you'll be let go if you're 'innocent'.
A self-destruct function, e.g. you give out the wrong code 3 times and your device wipes the data. Useful for military use cases where the data is worth more than the life of the person holding it.
Edit: I think we're on the same page. That's why I said it doesn't seem to be relevant here. I don't see how it could be pulled off conveniently within html.
I would love to see it worked out in a way that it would output different content depending on password.
It's really unclear what your point is here.
Furthermore weak encryption is worse than no encryption if it encourages dangerous behavior.
I would add that dropping ssl because you are using something like this would be dangerous behavior.
This doesn't require compromising any servers, and a lot of laptops will configure their DNS settings based on what the local network's DHCP server sends them.
To the end user, it will appear as though nothing is wrong.