Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Password-protect a static HTML page (robinmoisson.github.io)
348 points by yoble on June 14, 2017 | hide | past | favorite | 149 comments



In highschool I realized that my school's grading system was using a javascript scheme to control access to grades online:

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)


My first year of computer science, I was bored in the labs one day working on a basic Pascal programming assignment. Back then, our university had a VAX mainframe system that everyone worked on (staff and students alike).

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.


Why didn't you report it anonymously then?


Small town, small class, small faculty - makes it all hard to stay anonymous. Plus there wasn't any formal reporting method that I knew of at the time.

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.


decided to log back in using my course unit (INF180) as the username and password...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.

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.


For what it is worth, this was in a small town in Australia back in the early 80's... Simply a case of lazy admins (see my comment reply above). Probably even only down to one guy's slack work ethic.

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.


Back in high school (private boarding school) it was one of the math teachers who was running the mainframe. (And teaching the programming class.) Security consisted of students trying to break into each other's accounts and leaving Easter Eggs in each other's BASIC games.


Speaking as someone who checked the security of quite a few colleges in the 90s, I can say that for the most part, almost no one then had any idea that security was even a thing. So if they really were somehow better in the 80s it didn't last long.


Security was pretty sucky in both of those decades, but I didn't think anyone would have to fear for pointing that out.


Back in college I did a few things that today, might have netted me a visit by the Net Cops [1], but since I knew the sysadmins of the systems in question, I never got into trouble. A friend of mine though, who wasn't friends with the sysamins, did get in mild trouble.

[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


It all comes down to the campus culture. Our CS Dean at the time was an 'old school' cranky pants kind of guy, so I don't think he would have taken kindly to such a breach.

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.


From the way we've seen most schools respond to these types of reports from students you have to wonder if you were lucky that you couldn't figure out how to report it!


The time I accidentally took down the entire school website, I luckily did it at school and immediately told my understanding math teacher, who told IT directly, who came and asked me what I'd done, and fixed it within a couple minutes.

In retrospect I dodged a huge bullet!


Definitely. My high school's school district made a similar mistake with enabling directory listings, enumerating hundreds of documents with words like "Confidential" and "Audit Report" in the file names. Tried to report it at the time but I got the runaround from the school office; years later I'm glad I didn't manage to get any further with it.


When I found a way to bypass the login process back in university and thereby gain access to the previous users' network storage in university, I reported it anonymously for that very reason.


Circa 2005, we got hired by the district for finding problems.

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.


"zero tolerance"


I had a CS professor that had his own custom grade site written in Racket.

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.


Did something similar once, then a friend of mine found out the password within 5 minutes using a simple google rainbow table search. So make sure to at least salt it :)


And always perform hash verification or decrypting client-side so you can prevent brute-force attacks (purposely slowing down the hash verification or decrypting to 100ms is okayish already).


> 1. Concatenate the username and password, hash the combination

So if you change your password, you cannot access your grades? How is this okay?


You just can't change your password. If you want to change it, you go tell your teacher your new password, and then when they update grades, that's the password that will work.

Of course, each set of grades is managed by each teacher individually, so you would have to individually update your password on each "system"...


Change your password? how silly :D


The system accepting your password change updates the HTML file would be my guess.


Not that I recommend this, but if you want a (US) school to fix a grading security issue, you threaten to sue because exposing grades is a FERPA violation and schools could lose funding.


I was able to enter my high school's student information and grading system without any kind of authentication. I didn't really know much about computers at the time, so I was just looking through the applications installed on one of the nicer media lab computers and found the access portal. I didn't change anything though, but only because the lab teacher seemed suspicious already.


I hope at least they discouraged crawling of the pages using robots.txt otherwise a directory listing would index all the sub-pages. If you're really unlucky they might even end up in web.archive.org.


Encrypted page includes javascript from 2 CDNs, one for jQuery and one for "crypto-js". The jQuery one has an integrity hash, but "crypto-js" does not. Granted, they both use HTTPS...

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?!


Using a CDN is only a problem if it's compromised, which is unlikely to be a threat for most applications. You can avoid this entirely by using Subresource Integrity:

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="-->


Oops thanks, that should be fixed - the generating page now gets its libraries from CDNs.

I'll probably look into adding Subressource Integrity checks for the other two as well.


It is also a threat if your DNS is compromised.


Not when fetching over HTTPS.


The CA system is extremely broken, it won't protect you from a state actor. Also TLS + DANE is useless if the DNS is compromised.


That's a bit too much hyperbole to be useful: yes, a state which runs a trusted CA is a threat (at least for sites which don't use key-pinning) but there are a ton of other things you're at risk for that way like SMS-based auth and the police or black bag squad paying you a visit. Describing the CA model as extremely broken because it doesn't handle an out-of-scope threat doesn't help anyone change their behavior to avoid it.


Stack Overflow is riddled with questions from people asking how to do incredibly basic things "in jQuery."


I think this one is satire, but you never know ;) http://i.imgur.com/Q3mkcnl.gif


Werry_Togan is an excellent username haha. There's a lot of subtlety to this.

https://en.wikipedia.org/wiki/Terry_Wogan


I especially like the creativity in the "related questions".


"How can I use JavaScript to parse some HTML using regex?"

Priceless.


There's one that says "Where are my legs?" Took me a second to get but I think it's a reference to head and body in HTML.


That is definitely satire.


My highest rated answer on Stack overflow, by an enormous margin, is a simple jquery question (How to get the value of a textarea).


Is the answer "you don't need jQuery for this"? :)


I like the idea of the page relying as little as possible on my code (you have a better chance to trust a well known public CDN on HTTPS than some minified code inlined from an unknow github repo).

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 !


I don't mean this to sound sarcastic, but you seem to be knowledgable enough to make a pull request to the open source project?

[Edit: looks like this may already be on the way to addressing your issue https://github.com/robinmoisson/staticrypt/issues/1]


Embedding the crypt.js library in the resulting page would essentially pin the page to the version that was current at the time the HTML was encrypted. That could be problematic if there's a bug in the library.


OTOH it makes the HTML file require an Internet connection to view.


While it's true that jQuery is unnecessary, why does it matter? For one this is just a simple example to show off something cool that's possible that many people wouldn't initially think would be, I highly doubt that this is meant to be used seriously but more importantly it re-writes the entire page once the passphrase is found which overrides the jquery dependency and all other dependencies.

Why do people like to complain so much?


jQuery stays in the JS namespace even after its <script> is gone.


You're right, I looked back and it does in fact stay in the namespace.

Disregard my comment.


I remember in ~2005-2009 while I was in high school, javascript password-protection was my main interest, since I only had access to free hosts that hosted static files.

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].

[0] https://www.javacrypt.com/Course/


I remember 3-4 years ago when I was working with a major wall street financial company to integrate with their credit card processing gateway, some of the private and sensitive information (contracts, testing reports etc.) had already been communicated with a similar but proprietary AES 256 based encryption on a static HTML page via email attachments as a way of secure communication. The intended recipients would get an invite to their site to register/login to get the passphrase to unlock the encrypted static HTML doc. This could have been the standard practices in many financial firms theses days (when they are not using PGP/GPG encrypted emails)

Edit: redacted the name of company.


I believe SendSafely (https://www.sendsafely.com/) claims to have a somewhat secure/streamlined implementation of this. Browser non-plugin JavaScript crypto is always sketchy, but possibly better than nothing if the limitations are correctly communicated to the user.


SendSafely's workflow is quite different[1] from what I described with the encrypted static HTML email attachment. And I don't like the idea of sharing the confidential data over 3rd part cloud storage even if it's encrypted.

[1]: https://www.sendsafely.com/howitworks/


I agree there are differences, including transit route and format.

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.


It does not seem to work for me on multiple machines. I just get an incomplete HTML file that ends abruptly after the "border-top" CSS line. There is no closing semicolon to the line, the file just ends in the middle of the style element.

My input doesn't seem to matter, but I used:

<html><body>Hello</body></html>

Password: abcdefg


Welcome to the brave new world of web, "Optimized for IE5.5+" making a beautiful reincarnation with pages that only work with Chrome and silently fails on Firefox.


Thanks for the heads up - I'm reproducing it on firefox, I'll investigate asap.


Same here.

<head> is truncated.


Retry it without the html tags


If true, this is confusing because the placeholder text on the page is literally "<html><head>…" so they are encouraging a feature they don't support.


Still not working.


Thank you for the reports, @thread.

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.



I just updated Firefox to 54.0. It seems to work now!


Same here


I remember very distinctly about 15 years ago there was a site that had a "members only" page that had some reports that I really wanted (names/addresses/emails of the members of the org - I wanted a quick and easy lead list for a product I wanted to sell to them). I could see through a simple view source (remember, no chrome dev tools back then) that it wasn't some server side check of the password (the members knew it, there was no associated username).

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.


Unauthorised access and for financial gain - serious prison time awaits for such things in USA and UK. Take care!


Back in the day we used to use Apache basic authentication for this, that was before single page apps. Not you do have jwt that is explicitly designed to handle things like offline progressive web app logins.


As I read the title my first thought was "Huh? htaccess?"


Oooh, this is pretty cool. All that it needs is a cli utility so I can plug it in my scripts, and I can just tell my static site generator to encrypt specific pages while building.


That would be cool! Maybe a gulp plugin or somthing, that would wrap your pages with that, and then set a cookie or something.....


Thank you for inspiration. I've created nodejs module to encrypt files. Now wondering if we can make webpack bundle-loader that will load encrypted chunks. How cool would be that? What u guys think?


I did something like this some time ago, to send reports securely to people who'd never heard of PGP.

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.

http://ivo.palli.nl/encryption/encryption2.html


If only the web server software could do this for you...


It should be quite easy to make an nginx plugin for that.


Simple and useful. The perfect "Show HN".


There are many caveats. For example, the server and the connection must be trusted. Otherwise, an attacker can the javascript to send himself a copy of your password.

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.


A feeling of saying "what is this familiar thing":

http://www.acme.com/software/securepage/

(2010 or earlier, basically does similar trick, from the authors of thttpd, mini_httpd and micro_httpd!)


I didn't find that one when I looked for this kind of tool so I rolled out my own, I would have definitely given it a go !


I wrote a little web app very similar to this last year: https://hypervault.github.io/. The difference is mine was mostly focused on file encryption.


That is cool :D


That's a fun toy.. and a great example of how easy it is to get crypto wrong. I'm just guessing here, but you are probably missing some key derivation like PBKDF2.

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


crypto-js has PBKDF2 functionality. What part of it this did you find wrong? Preferably not a guess, but something more concrete that can be informative for other readers. For example, could you provide some insight on why the two libraries that you link to better for this use case?


You've somewhat rolled your own crypto. For instance, you've manually HMACed separately and appended it to the message, and you've chosen which encryption primitives to use. In this case, I don't see anything wrong (you've used encrypt-then-mac, which is the recommended way of doing it).

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.


> I'm just guessing here, but you are probably missing some key derivation like PBKDF2

How could you use AES with a passphrase with no key derivation function?


Reminds me of this: https://news.ycombinator.com/item?id=10901745

Similar, but uses files instead of HTML text.


Interesting. What is the use case for this versus HTTP basic auth?


You don't need to control the server

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.


A lot of static hosting methods don't make it easy to implement HTTP basic auth. The beauty of this approach is it's completely transparent to the network/application layer. You can use this with just some files on S3 or GitHub Pages, for example.



It's self-contained so you can serve/share it statically. HTTP basic auth requires a server backend configured with the credentials.


HTTP basic auth does not provide encryption.


A static website on S3.


Pretty pretty neat. I built [something pretty similar](https://devpost.com/software/cryptopostal) to give my address to family & friends during the holidays. Includes a node generator to make your own. Enjoy :)

[video demo](https://youtu.be/zevMEiR2CZY)


This would be neat if you could build a wrapper of this around GitHub pages. Then you could finally use GitHub pages sites for private content!

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."


In part it depends on the strength (and secure transmission of your passphrase (though if you have a good way of transmitting the passphrase this becomes less useful))

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.


The pass phrase also can't be changed, without reencryping the entire page. Once leaked, the contents are effectively publicly available.

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.


I considered both these points when I was composing my answer but came to the conclusion that this is true for basically any encryption strategy, if I've transmitted contents signed with your public key then when your private key becomes known so does the contents.

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.


True, but if there's one shared key for each page, the chances of that key getting loose are higher. There are alsomethods of encrypting a message where you can specify multiple recipients (i.e. multiple keys), letting you remove one key without affecting the viewership of the page for people with the other keys.

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.


you could just do the encryption on the server side, in which case you just change the key and done.

/s


Doesn't the GitHub pages content itself live in a repository visible to all? One could just look up the password. Or is it possible to have pages for private repos as well?


The passphrase wouldn't be included in the repo; that's the purpose of using client-side encryption.


What Darphe said in their reply. But yeah, you can setup pages for private repos. That's mainly what I was thinking. I currently do that for a few projects. You can have a private repo and still use github-pages, it just obviously exposes the pages to the public technically (but not the repo code).


Not an encryption expert, and would likely use it myself.

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.


I'm no expert but I think if they use a cryptographic function that requires a lot of CPU cycles, such as bcrypt, it will still be hard to brute force as long as you use a secure password. It looks, however, like they might have used something like sha256. I don't think that requires a lot of CPU and so it's much easier to brute forced.

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.


short answer: no, it's not secure

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.


I had built something along these lines. Not really encrypting the page. But allowing you to send each other Base64 data: http://cloak.websrvr.in/ . I had built it to circumvent enterprise email servers which don't allow sending binaries. Which is kind of ironic because email sends attachments as Base64.


And no one mentions TiddlyWiki[0]...

[0] http://tiddlywiki.com/


I did something similar to this for redacting HTML pages a while back, although I never fully polished it: https://github.com/alexbecker/redact-js

It's not something I'd use for serious security applications, but fun for interactive fiction.


This is cool! To really make the overhead tiny, include an inplace implementation of XTEA (under 1KB decryption).

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.


Not sure, but this might be useful and/or interesting to some HN'ers

https://github.com/ezWebDevTools/ezCryptoJS


It's pretty cool. I entertain the idea of doing this and hadn't thought of it ever, but how do you see it being used if I can't use it with a python/node.js API to deploy pages on the fly?


Rubber hose encryption would be a neat add here!


Do you mean plausible deniability? That would be hard to accomplish on a static file, since there's no logical reason it would include 'empty space' in the way an encrypted hard disk does.


I don't think so. There was an encryption scheme thought up and partially implemented about a decade (or two?) ago that allowed for an arbitrary number of partitions to exist in a single encrypted drive. It was called 'rubber hose' because the scheme was designed such that it was impossible to determine how many partitions existed inside the encrypted drive.

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)


Thank you. I hadn't heard of this concept before. I think it could be relevant here.

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.


One might still reasonably expect that the person who created the file has passwords that decrypt 100% of it.


Right; the point is that when you're the interrogator holding your 'rubber hose', when do you know to stop asking for more passwords? There might be 2, there might be 20. Your suspect will put up the same resistance (theoretically) for each password.

Edit: of course, sucks for the suspect if the interrogator doesn't consider their life valuable.


That is exactly what I was referring to. An HTML file has no empty space to hide something in.

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.


If the tool always makes a large blob of noise to hide the HTML in, and accepts an arbitrary number of key/html pairs it seems like this could work in the browser. Would seem to just cost disk space to be viable.


The 'empty space' is the encrypted blob. The unknown variable that the rubber hose encryption system exploits is that the interrogator doesn't know what's inside that blob, and there might be several 'partitions' inside.

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.


This is essentially what encrypted pastebins do (but they usually put the key/password in the URL hash).


That is awesome!

I would love to see it worked out in a way that it would output different content depending on password.


In 2017, one ought to use browsers' native crypto API instead of doing crypto in js...


Just fyi on the native front our team recently started work on npm package webcrypto-crypt in conjunction with some experiments utilizing IPFS hypermedia and modern web browsers. Maybe others will find it useful: https://www.npmjs.com/package/webcrypto-crypt


Browsers have a native crypto API? Last I heard, websites requiring client side crypto used libraries written by other people. There's even a Node.js module for crypto.[0]

[0]: https://www.npmjs.com/package/crypto-js



Seems very cool, but I don't see the use-case. Anyone can help me?


Static site on CloudFront?


For some reason it doesn't work with password 123


The password "123" is working for me, if you find steps to reproduce do let me know !


Now make a WP plugin and you're set!


WordPress has access to server-side scripting, why would you use js encryption there?


- Allows transferring encrypted data over an insecure network - Page can be loaded online and decrypted/read offline later - Server cannot track who successfully decrypted the information - If server is compromised by a third party, they cannot retrieve the encryption key from users viewing the document - Among other things


We use JS encryption heavily in a number of our webapps, so I'm not unfamiliar with its advantages. But relying on JS encryption to provide "security" over unencrypted HTTP is just asking for trouble. It's the "secure on paper, broken in practice" kind of thing that ends up being a huge liability.


Why do you speak of unencrypted HTTP? Who cares? Only AES-256 encrypted data is sent and it's decoded locally. You could publish it on the front page of the New York Times (if anybody reads that anymore) and be secure, because you are publishing encrypted content.

It's really unclear what your point is here.


Your unencrypted (or just unauthenticated) HTML page might suddenly start sending the password you enter elsewhere...


Really, how? Because somebody compromised the server? So what? If they did that, all bets are off.


No, because someone MITMs your insecure channel and serves you a malicious page that steals your password and the unencrypted data.


The OPs point is very clear. Js encryption has a lot to do to prove itself before it should be trusted with production secrets.

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.


Keep in mind that a third party who has compromised the server could change the JavaScript to report password entries back to it.


You are concerned with a compromised server? If I control your server, I can harvest whatever a user types in, even on an HTTPS page.


With plain HTTP, it'd be very easy for someone running an open WiFi station or a corrupt ISP to set up a DNS server that points the domain to their own reverse proxy that then can modify the page that the user receives to include some additional JavaScript to forward the user's password or the decrypted page results after the user inputs their password.

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.


That's true, but I was responding to a specific claim in the parent post


There's basic authentication for protecting static web pages. It's no better or worse than any other password scheme.


I could see some other nifty concept coming alive because of this.


From the source code I was unable to deduce what KDF and Block mode is used with it. Does anybody know what does it use? crypto-js seems to support multiple different KDFs and Block modes.


doc says it defaults to cbc, not sure about the kdf




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: