17 ms·

Challenge HN: Break my in-browser crypto for $1000

88 points by absherwin 13y ago

After reading arguments about using cryptography in the browser, I wanted to see how easy it was to fail in practice so I built a simple app: notecrypt.appspot.com. It encrypts notes using SJCL and stores their encrypted form on the server and enables retrieval with the same credentials. This approach is uniformly as good as or better than a browser app not using in-browser crypto from a security perspective. As daeken noted in a discussion a few days ago, it provides protection against a demand to produce the notes. He also claims that "For all other cases, there are a million simple means by which you can break it." So I challenge anyone on HN: Show me such simple means. The instructions for claiming a reward are contained in a note stored in the app's database. To help you along, I'll navigate to any URL you send me while logged into the site. If you'd like to try your hand at finding a vulnerability in the AES implementation used, I'll send you a snapshot of the database. If you want to try injecting code, I'm happy to use a network you control if we can arrange the logistics though I won't promise to log in if you can't provide a valid SSL certificate :). If you need assistance to demonstrate a reasonable attack, ask. Post your attacks below or email my user name @gmail.com. The first successful attack wins. Usual disclaimers apply. You might argue that this doesn't prove anything about JavaScript cryptography since additional security is used. That's true. If this survives, it doesn't provide evidence that the in-browser cryptography is sufficient; it only suggests that it can defeat some additional threats against an otherwise secure application.

napoleond 13y ago
The problem with in-browser crypto is way bigger than the feasibility of properly implementing crypto in the browser--it's the fact that you can never ensure the security of the network. As such, I think the prevailing argument against in-browser crypto is that it provides a false sense of security. EDIT: Nevertheless, this seems like a neat project! I'm not anything resembling a pentester though, so I'll leave the challenge to the experts :)
- absherwin 13y ago
  Network security is a problem but breaking https doesn't seem trivial in the wild. That's why I'm inviting people to try exploits on a real app and willing to use a malicious network to let them break it.
  - e1ven 13y ago
    So let's talk this through. I think the idea behind crypto in the browser is cool, but it seems like anytime you're requesting the JS from the server, you need to trust the server - Instead of serving crypto.js, you could server plaintext.js, and I wouldn't ever notice the difference, would I? So if we agree that I need to trust you, to serve the JS crypto properly, then what's the difference between doing that and trusting you to encrypt the text for me?
    - absherwin 13y ago
      Yes, you need to trust me. I'd argue it's easier to trust me if the crypto is happening on the client since if I change it, I could be caught. The probability of being caught in any one instance is very low but over many instances is high. Would you make the same argument for native application? Unless you read the source code every time you upgrade, you're exposed to the same risk. cperciva did an inadvertent real world experiment on this by making an error during a refactoring of Tarsnap and it took 19 months for a subtle crypto bug to be noticed.
      - e1ven 13y ago
        If you changed it globally, you might be noticed next time someone did an audit, which I suspect would be rare. If you added a backdoor on the server that said "If userid == e1ven{crypto.js = plaintext.js}" it would be much harder to detect. Hushmail did something similar with a modified version of it's Java applet, back a few years ago- http://www.wired.com/threatlevel/2007/11/hushmail-to-war/ http://www.wired.com/threatlevel/2007/11/hushmail-to-war/ My point isn't that you should never trust webapps - It's that doing the processing in JS, or on the server, doesn't CHANGE the threat-model. In both scenerios, I need to trust you an identical amount, so there's no security advantage do doing the crypto on the client side.
        pyre 13y ago
        Well, it's slightly different. Every person might not check every single time, but it would be possible to do something like write a browser plugin (or setup some sort of automated system) to check what was going on since the execution is happening client-side. I made sure to emphasize 'slightly' because this could just trigger an arms race to getting around detection. You might be safe if you kept your detection methods a secret (and only personally used them). On the other hand, if the detection methods were used/deployed on a wide scale, then anyone trying to compromise you would just work around the detection.
nwh 13y ago
Consider using crypto.randomBytes() for your key generation.
- absherwin 13y ago
  SJCL fills its initial entropy pool with crypto.getRandomValues()
  - nwh 13y ago
    Apologies, I missed that on first glance. I'm not sure why you'd want to run your CSRNG through a bunch of additional functions, at best you're doing nothing, at worst you're reducing the quality of the entropy.
    - absherwin 13y ago
      NP. Checking code is a good. It's not the clearest code since the initialization is located separately from the main RNG function. If you actually tried to read the inline minified version of SJCL, I'm sorry but impressed.
borski 13y ago
Clickable: https://notecrypt.appspot.com/ https://notecrypt.appspot.com/
aidenn0 13y ago
Here's the issue I have with in-browser JS crypto: let's say I compromise your server, I can now send code that uploads all of the user's keys to me, without needing to compromise their individual machines. There are similar issues with auto-update mechanisms; if someone owns the chrome auto-update system then they can run arbitrary code on everybody's machine. That's higher-stakes, but also more secure than the average webserver (which if javascript crypto were to become ubiquitous, would become an issue)
- nwh 13y ago
  > if someone owns the chrome auto-update system then they can run arbitrary code on everybody's machine It would be easier to compromise a large browser plugin's source control. If say, AdBlock was compromised, that's tens of millions of users that would be running malicious code with absolutely no indication that the update even occurred. With DOM level access on every page a user browses to, an attacker could just compromise passwords, inject their own advertising, attempt to gain higher access, etcetera. For the case of the OP, that would mean that the client side encryption would be rendered worthless.
- absherwin 13y ago
  What's an alternative implementation that encrypts the data at rest and is more resilient to a compromised server?
  - tptacek 13y ago
    A downloadable client that doesn't bootstrap its own crypto every time it runs from your server. Can I have my $1000 now? Actually: I'd prefer if you just sent it to Partners in Health; they're great.
    - absherwin 13y ago
      We can argue about the merits of downloadable solutions but that isn't a flaw in this application. I'm willing to make it easy for you: You can even have the database to let you crack it without first having to break into my server. I agree with you that there are risks to browser side crypto but how are they any different from upgrading software without reevaluating the security of each upgrade? Browser-based crypto also has benefits; most users prefer using web applications to installed all else equal because it's easier.
MichaelGG 13y ago
What does this provide over just using SSL and deriving a key from the user's password and doing crypto on the server? Nothing. Anyone that compromises the server can compromise the client and have it send the keys back. Your test is just pointing that SSL is useful; all the security hinges on SSL.
- absherwin 13y ago
  Having a server compromised is bad. Which is worse, the ability to read plaintext on the server silently or forcing a code change to be distributed to every user, however subtle? That said, the key for security is to design an app where compromising the server isn't possible.
  - nwh 13y ago
    > Which is worse, the ability to read plaintext on the server silently or forcing a code change to be distributed to every user, however subtle? I would say that the latter is far more severe. People are going to be a lot more complacent when they believe that the data they are storing can't be accessed by others, or is otherwise immune to attacks. There's also the distinct possibility that the user is going to be storing sensitive information that they wouldn't normally store anywhere but locally. Don't get me wrong, I love encryption, I just get uneasy around browser implementations. There's some very fragile ones in use at the moment (see mega.co.nz, blockchain.info).
    - absherwin 13y ago
      I'm uncomfortable with arguments that are equivalent to PerceivedBenefit(X)>RealBenefit(X) and RealBenefit(X)>0 but NegativeBenefit(Actions|PerceivedBenefit(X))>RealBenefit(X) so X should be banned. Since PerceivedBenefit(X) and Actions will both vary by individual and are controllable through learning and discipline, I'd rather give individuals the right to choose. Equivalent examples: Seatbelts are bad since people will drive recklessly; calculators are bad since people won't bother learning arithmetic; cars are bad since people will walk less. In each case, the negative does occur. I'd argue that as a whole society is better for all of those.
tptacek 13y ago
http://www.schneier.com/crypto-gram-9902.html#snakeoil http://www.schneier.com/crypto-gram-9902.html#snakeoil See "Warning Sign #9".
- absherwin 13y ago
  This isn't a product launch. It's a demonstration to focus discussion.
  - tptacek 13y ago
    I like that! From now on, when you want to introduce some new crypto idea, just make sure not to call it a "product", then issue a $1000 contest to assure people the idea works. Why doesn't everyone do that? Oh, wait, I think Schneier answered that: Contests are a terrible way to demonstrate security. A product/system/protocol/algorithm that has survived a contest unbroken is not obviously more trustworthy than one that has not been the subject of a contest. The best products/systems/protocols/algorithms available today have not been the subjects of any contests, and probably never will be. Contests generally don't produce useful data. There are three basic reasons why this is so. They are: 1. The contests are generally unfair. 2. The analysis is not controlled. 3. Contest prizes are rarely good incentives. I'd submit that (1) doesn't count here, because the idea you're demonstrating is so obviously flawed that contestants aren't at any disadvantage. But (2) and (3) are absolutely valid here: there's no structure to the contest (it's a bunch of Hacker News people poking at a page at random with no collaboration, milestones, or test plans), and $1000 buys ~3 hours of cryptanalysis work if you source it from software security people instead of actual cryptographers (who bill north of $450/hr). I have no idea who you are and so I don't want to sound like I'm offended by what you've posted. But you are like the 100th person to staple SJCL onto a web app and posit that they've created something more secure than a private wiki. Actual professional cryptographers have addressed similar claims in the past. Here's Nate Lawson: http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/ http://rdist.root.org/2010/11/29/final-post-on-javascript-cr... Instead of the brinksmanship of offering a contest, why don't you instead just listen to the arguments people are making and try to learn from them? Triple bonus points for noting that AES and SHA3 were the products of design contests, after Schneier wrote this, and then observing the differences between those design contests and the one at the top of this thread.
oconnore 13y ago
You have acquired just enough rope to hang yourself with.
h8trswana8 13y ago
I don't see any key being stored client side. So you must be deriving the key from my password? If that's the case, then my attack would be: * Loop through a list of common passwords. * Derive keys from those passwords. * See if any decrypted results return an ASCII-like result.
- absherwin 13y ago
  That would work for a sufficiently broad definition of common. You're welcome to try. The challenge is that it'll take a long time unless you have incredibly fast hardware or are very good at guessing.
  - h8trswana8 13y ago
    Eh, whatever key derivation algorithm you are using is running in a browser, and isn't throwing any long-running JS exceptions. And I didn't see my browser block. So it can't be that expensive. From an academic viewpoint, it's not really strong encryption if your AES key is derived from a password. Your key space is limited to ASCII characters, and 99% of users will not choose a strong password. So from my perspective, if you sent me a DB dump, I could read almost everything.
    - absherwin 13y ago
      Email me and I'll send you the DB dump. You can brute force it . I don't think it's as trivial as you suspect but I'd love for you to prove me wrong.
      - h8trswana8 13y ago
        It's trivial to brute force for anyone who has a weak password. More importantly, it's trivial for an adversary who cares. If I'm encrypting a note containing state secrets to send to a foreign intelligence officer, the NSA has the technology (and more importantly, the resources) to brute force their way in. And if your password is too complex to crack (read: a 256-bit key), you probably can't remember it either, which means you have to write it down somewhere; so an adversary who cares would find an outside channel (subpoena, hack your personal computer) to determine your key. What is your key derivation algorithm? PBKDF2?
AnIrishDuck 13y ago
This is bad even as contests go. 1) You don't provide a concise summary of what threat models you are considering. So in that case, my attack is: I break into your server and silently swap your code with code that ships me your user's password. 2) You don't even give a human readable listing of your site's source code. Reverse engineering is tedious work that's entirely different from cryptography or security analysis. You can be sure that any motivated attackers will have skilled reverse engineers deconstruct your system and then hand off their results to skilled security analysts/cryptographers. But that sure as hell will cost more than the paltry $1000 you're offering here.
- absherwin 13y ago
  1. I proposed a few examples: Crypto flaws that you could exploit by giving you the ciphertext (only 1 person has asked), cross-site request vulnerabilities, and attacks from a malicious network. I also invited you to propose your own attacks. 2. You have the client side code. I'm happy to provide the remaining code if anyone is actually curious.
  - AnIrishDuck 13y ago
    1. I don't see how any of these threat models can't be addressed by doing server-side crypto. Server-side crypto libraries are more mature, more reviewed, and thus by default better from a security standpoint. 2. The client side code is obfuscated. The server-side code is not provided. To perform a reasonable analysis of a system's security, a reviewer needs unobfuscated access to both. Why would you try and make security and crypto researchers de-obfuscate or guess your code, when that is not their specialization?
    - absherwin 13y ago
      1. As discussed in another comment, this requires a similar level of trust to encrypting the data on the server. The only difference here is that, to the best of my knowledge, an attacker who took control of the server, could silently log the plaintexts in the server side case while some indication would be provided in the client-side case. Most wouldn't notice it but some would eventually. 2. The code I wrote isn't obfuscated. The code at the top is just SJCL and angular.js which are https://github.com/bitwiseshiftleft/sjcl https://github.com/bitwiseshiftleft/sjcl and https://github.com/angular/angular.js https://github.com/angular/angular.js
moxie 13y ago
You posted the link like this: "...I wanted to see how easy it was to fail in practice so I built a simple app: notecrypt.appspot.com" If you copy and paste that into your browser, your browser will make an HTTP request. Your webapp will send back a 302 redirect with an HTTPS link, but if I'm an attacker running sslstrip (http://www.thoughtcrime.org/software/sslstrip http://www.thoughtcrime.org/software/sslstrip), that won't work. What's more, you don't set HSTS headers: $ curl -i https://notecrypt.appspot.com/ https://notecrypt.appspot.com/ HTTP/1.1 200 OK ETag: "ibqapA" Date: Wed, 29 May 2013 18:59:37 GMT Expires: Wed, 29 May 2013 19:09:37 GMT Cache-Control: public, max-age=600 Content-Type: text/html Server: Google Frontend Transfer-Encoding: chunked ...so anyone that types "notecrypt.appspot.com" into their browser in the future will continually expose themselves to the same vulnerability. At that point I can just modify the JS that gets transmitted back to the browser such that it doesn't actually do any encryption. As always webapp-based JS cryptography is reducible to the strength of SSL. If I can break SSL, I can break your JS crypto, so there's really no point in doing the JS-based crypto. How do I collect the $1000?
- deleted 13y ago
  [deleted]
- absherwin 13y ago
  The instructions are in a note. If I understand your attack, you'd need to set up a clone website that resends the password in the clear, have a malicious network redirect me to it and get me to enter my password. I'm happy to enable to you to demonstrate that it works. The hardest part is presenting a valid SSL certificate. As I warned in the initial post, "I won't promise to log in if you can't provide a valid SSL certificate." Email me and we can arrange the details.
  - michael_h 13y ago
    Didn't Iran get a valid SSL certificate for *.google.com a while ago? Edit: Found an article, by cperciva no less: http://www.daemonology.net/blog/2011-09-01-Iran-forged-the-wrong-SSL-certificate.html http://www.daemonology.net/blog/2011-09-01-Iran-forged-the-w...
loumf 13y ago
Can you explain what this means exactly: "I'll navigate to any URL you send me while logged into the site." If I give you a URL what exactly are you going to do? Also, when logged into the site, are you logged into the account where the note with claim instructions was made?
- absherwin 13y ago
  I'll paste it into another tab in a browser that has me logged into the account or I'll log into the account after pasting the link. Whichever you prefer. If you have another proposal, as long as it's something reasonable, I'm happy to entertain it.
nicksdjohnson 13y ago
tl;dr: You've set up the challenge in such a way that demonstrating any of the threat models against which client side crypto is weak would require compromising other layers of security first that are out of scope for the challenge.

88 points by absherwin 13y ago

napoleond 13y ago

The problem with in-browser crypto is way bigger than the feasibility of properly implementing crypto in the browser--it's the fact that you can never ensure the security of the network. As such, I think the prevailing argument against in-browser crypto is that it provides a false sense of security. EDIT: Nevertheless, this seems like a neat project! I'm not anything resembling a pentester though, so I'll leave the challenge to the experts :)

absherwin 13y ago
Network security is a problem but breaking https doesn't seem trivial in the wild. That's why I'm inviting people to try exploits on a real app and willing to use a malicious network to let them break it.
- e1ven 13y ago
  So let's talk this through. I think the idea behind crypto in the browser is cool, but it seems like anytime you're requesting the JS from the server, you need to trust the server - Instead of serving crypto.js, you could server plaintext.js, and I wouldn't ever notice the difference, would I? So if we agree that I need to trust you, to serve the JS crypto properly, then what's the difference between doing that and trusting you to encrypt the text for me?
  - absherwin 13y ago
    Yes, you need to trust me. I'd argue it's easier to trust me if the crypto is happening on the client since if I change it, I could be caught. The probability of being caught in any one instance is very low but over many instances is high. Would you make the same argument for native application? Unless you read the source code every time you upgrade, you're exposed to the same risk. cperciva did an inadvertent real world experiment on this by making an error during a refactoring of Tarsnap and it took 19 months for a subtle crypto bug to be noticed.
    - e1ven 13y ago
      If you changed it globally, you might be noticed next time someone did an audit, which I suspect would be rare. If you added a backdoor on the server that said "If userid == e1ven{crypto.js = plaintext.js}" it would be much harder to detect. Hushmail did something similar with a modified version of it's Java applet, back a few years ago- http://www.wired.com/threatlevel/2007/11/hushmail-to-war/ http://www.wired.com/threatlevel/2007/11/hushmail-to-war/ My point isn't that you should never trust webapps - It's that doing the processing in JS, or on the server, doesn't CHANGE the threat-model. In both scenerios, I need to trust you an identical amount, so there's no security advantage do doing the crypto on the client side.
      - pyre 13y ago
        Well, it's slightly different. Every person might not check every single time, but it would be possible to do something like write a browser plugin (or setup some sort of automated system) to check what was going on since the execution is happening client-side. I made sure to emphasize 'slightly' because this could just trigger an arms race to getting around detection. You might be safe if you kept your detection methods a secret (and only personally used them). On the other hand, if the detection methods were used/deployed on a wide scale, then anyone trying to compromise you would just work around the detection.

nwh 13y ago

Consider using crypto.randomBytes() for your key generation.

absherwin 13y ago
SJCL fills its initial entropy pool with crypto.getRandomValues()
- nwh 13y ago
  Apologies, I missed that on first glance. I'm not sure why you'd want to run your CSRNG through a bunch of additional functions, at best you're doing nothing, at worst you're reducing the quality of the entropy.
  - absherwin 13y ago
    NP. Checking code is a good. It's not the clearest code since the initialization is located separately from the main RNG function. If you actually tried to read the inline minified version of SJCL, I'm sorry but impressed.

borski 13y ago

Clickable: https://notecrypt.appspot.com/ https://notecrypt.appspot.com/

aidenn0 13y ago

Here's the issue I have with in-browser JS crypto: let's say I compromise your server, I can now send code that uploads all of the user's keys to me, without needing to compromise their individual machines. There are similar issues with auto-update mechanisms; if someone owns the chrome auto-update system then they can run arbitrary code on everybody's machine. That's higher-stakes, but also more secure than the average webserver (which if javascript crypto were to become ubiquitous, would become an issue)

nwh 13y ago
> if someone owns the chrome auto-update system then they can run arbitrary code on everybody's machine It would be easier to compromise a large browser plugin's source control. If say, AdBlock was compromised, that's tens of millions of users that would be running malicious code with absolutely no indication that the update even occurred. With DOM level access on every page a user browses to, an attacker could just compromise passwords, inject their own advertising, attempt to gain higher access, etcetera. For the case of the OP, that would mean that the client side encryption would be rendered worthless.
absherwin 13y ago
What's an alternative implementation that encrypts the data at rest and is more resilient to a compromised server?
- tptacek 13y ago
  A downloadable client that doesn't bootstrap its own crypto every time it runs from your server. Can I have my $1000 now? Actually: I'd prefer if you just sent it to Partners in Health; they're great.
  - absherwin 13y ago
    We can argue about the merits of downloadable solutions but that isn't a flaw in this application. I'm willing to make it easy for you: You can even have the database to let you crack it without first having to break into my server. I agree with you that there are risks to browser side crypto but how are they any different from upgrading software without reevaluating the security of each upgrade? Browser-based crypto also has benefits; most users prefer using web applications to installed all else equal because it's easier.

MichaelGG 13y ago

What does this provide over just using SSL and deriving a key from the user's password and doing crypto on the server? Nothing. Anyone that compromises the server can compromise the client and have it send the keys back. Your test is just pointing that SSL is useful; all the security hinges on SSL.

absherwin 13y ago
Having a server compromised is bad. Which is worse, the ability to read plaintext on the server silently or forcing a code change to be distributed to every user, however subtle? That said, the key for security is to design an app where compromising the server isn't possible.
- nwh 13y ago
  > Which is worse, the ability to read plaintext on the server silently or forcing a code change to be distributed to every user, however subtle? I would say that the latter is far more severe. People are going to be a lot more complacent when they believe that the data they are storing can't be accessed by others, or is otherwise immune to attacks. There's also the distinct possibility that the user is going to be storing sensitive information that they wouldn't normally store anywhere but locally. Don't get me wrong, I love encryption, I just get uneasy around browser implementations. There's some very fragile ones in use at the moment (see mega.co.nz, blockchain.info).
  - absherwin 13y ago
    I'm uncomfortable with arguments that are equivalent to PerceivedBenefit(X)>RealBenefit(X) and RealBenefit(X)>0 but NegativeBenefit(Actions|PerceivedBenefit(X))>RealBenefit(X) so X should be banned. Since PerceivedBenefit(X) and Actions will both vary by individual and are controllable through learning and discipline, I'd rather give individuals the right to choose. Equivalent examples: Seatbelts are bad since people will drive recklessly; calculators are bad since people won't bother learning arithmetic; cars are bad since people will walk less. In each case, the negative does occur. I'd argue that as a whole society is better for all of those.

tptacek 13y ago

http://www.schneier.com/crypto-gram-9902.html#snakeoil http://www.schneier.com/crypto-gram-9902.html#snakeoil See "Warning Sign #9".

absherwin 13y ago
This isn't a product launch. It's a demonstration to focus discussion.
- tptacek 13y ago
  I like that! From now on, when you want to introduce some new crypto idea, just make sure not to call it a "product", then issue a $1000 contest to assure people the idea works. Why doesn't everyone do that? Oh, wait, I think Schneier answered that: Contests are a terrible way to demonstrate security. A product/system/protocol/algorithm that has survived a contest unbroken is not obviously more trustworthy than one that has not been the subject of a contest. The best products/systems/protocols/algorithms available today have not been the subjects of any contests, and probably never will be. Contests generally don't produce useful data. There are three basic reasons why this is so. They are: 1. The contests are generally unfair. 2. The analysis is not controlled. 3. Contest prizes are rarely good incentives. I'd submit that (1) doesn't count here, because the idea you're demonstrating is so obviously flawed that contestants aren't at any disadvantage. But (2) and (3) are absolutely valid here: there's no structure to the contest (it's a bunch of Hacker News people poking at a page at random with no collaboration, milestones, or test plans), and $1000 buys ~3 hours of cryptanalysis work if you source it from software security people instead of actual cryptographers (who bill north of $450/hr). I have no idea who you are and so I don't want to sound like I'm offended by what you've posted. But you are like the 100th person to staple SJCL onto a web app and posit that they've created something more secure than a private wiki. Actual professional cryptographers have addressed similar claims in the past. Here's Nate Lawson: http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/ http://rdist.root.org/2010/11/29/final-post-on-javascript-cr... Instead of the brinksmanship of offering a contest, why don't you instead just listen to the arguments people are making and try to learn from them? Triple bonus points for noting that AES and SHA3 were the products of design contests, after Schneier wrote this, and then observing the differences between those design contests and the one at the top of this thread.

oconnore 13y ago

You have acquired just enough rope to hang yourself with.

h8trswana8 13y ago

I don't see any key being stored client side. So you must be deriving the key from my password? If that's the case, then my attack would be: * Loop through a list of common passwords. * Derive keys from those passwords. * See if any decrypted results return an ASCII-like result.

absherwin 13y ago
That would work for a sufficiently broad definition of common. You're welcome to try. The challenge is that it'll take a long time unless you have incredibly fast hardware or are very good at guessing.
- h8trswana8 13y ago
  Eh, whatever key derivation algorithm you are using is running in a browser, and isn't throwing any long-running JS exceptions. And I didn't see my browser block. So it can't be that expensive. From an academic viewpoint, it's not really strong encryption if your AES key is derived from a password. Your key space is limited to ASCII characters, and 99% of users will not choose a strong password. So from my perspective, if you sent me a DB dump, I could read almost everything.
  - absherwin 13y ago
    Email me and I'll send you the DB dump. You can brute force it . I don't think it's as trivial as you suspect but I'd love for you to prove me wrong.
    - h8trswana8 13y ago
      It's trivial to brute force for anyone who has a weak password. More importantly, it's trivial for an adversary who cares. If I'm encrypting a note containing state secrets to send to a foreign intelligence officer, the NSA has the technology (and more importantly, the resources) to brute force their way in. And if your password is too complex to crack (read: a 256-bit key), you probably can't remember it either, which means you have to write it down somewhere; so an adversary who cares would find an outside channel (subpoena, hack your personal computer) to determine your key. What is your key derivation algorithm? PBKDF2?

AnIrishDuck 13y ago

This is bad even as contests go. 1) You don't provide a concise summary of what threat models you are considering. So in that case, my attack is: I break into your server and silently swap your code with code that ships me your user's password. 2) You don't even give a human readable listing of your site's source code. Reverse engineering is tedious work that's entirely different from cryptography or security analysis. You can be sure that any motivated attackers will have skilled reverse engineers deconstruct your system and then hand off their results to skilled security analysts/cryptographers. But that sure as hell will cost more than the paltry $1000 you're offering here.

absherwin 13y ago
1. I proposed a few examples: Crypto flaws that you could exploit by giving you the ciphertext (only 1 person has asked), cross-site request vulnerabilities, and attacks from a malicious network. I also invited you to propose your own attacks. 2. You have the client side code. I'm happy to provide the remaining code if anyone is actually curious.
- AnIrishDuck 13y ago
  1. I don't see how any of these threat models can't be addressed by doing server-side crypto. Server-side crypto libraries are more mature, more reviewed, and thus by default better from a security standpoint. 2. The client side code is obfuscated. The server-side code is not provided. To perform a reasonable analysis of a system's security, a reviewer needs unobfuscated access to both. Why would you try and make security and crypto researchers de-obfuscate or guess your code, when that is not their specialization?
  - absherwin 13y ago
    1. As discussed in another comment, this requires a similar level of trust to encrypting the data on the server. The only difference here is that, to the best of my knowledge, an attacker who took control of the server, could silently log the plaintexts in the server side case while some indication would be provided in the client-side case. Most wouldn't notice it but some would eventually. 2. The code I wrote isn't obfuscated. The code at the top is just SJCL and angular.js which are https://github.com/bitwiseshiftleft/sjcl https://github.com/bitwiseshiftleft/sjcl and https://github.com/angular/angular.js https://github.com/angular/angular.js

moxie 13y ago

You posted the link like this: "...I wanted to see how easy it was to fail in practice so I built a simple app: notecrypt.appspot.com" If you copy and paste that into your browser, your browser will make an HTTP request. Your webapp will send back a 302 redirect with an HTTPS link, but if I'm an attacker running sslstrip (http://www.thoughtcrime.org/software/sslstrip http://www.thoughtcrime.org/software/sslstrip), that won't work. What's more, you don't set HSTS headers: $ curl -i https://notecrypt.appspot.com/ https://notecrypt.appspot.com/ HTTP/1.1 200 OK ETag: "ibqapA" Date: Wed, 29 May 2013 18:59:37 GMT Expires: Wed, 29 May 2013 19:09:37 GMT Cache-Control: public, max-age=600 Content-Type: text/html Server: Google Frontend Transfer-Encoding: chunked ...so anyone that types "notecrypt.appspot.com" into their browser in the future will continually expose themselves to the same vulnerability. At that point I can just modify the JS that gets transmitted back to the browser such that it doesn't actually do any encryption. As always webapp-based JS cryptography is reducible to the strength of SSL. If I can break SSL, I can break your JS crypto, so there's really no point in doing the JS-based crypto. How do I collect the $1000?

deleted 13y ago
[deleted]
absherwin 13y ago
The instructions are in a note. If I understand your attack, you'd need to set up a clone website that resends the password in the clear, have a malicious network redirect me to it and get me to enter my password. I'm happy to enable to you to demonstrate that it works. The hardest part is presenting a valid SSL certificate. As I warned in the initial post, "I won't promise to log in if you can't provide a valid SSL certificate." Email me and we can arrange the details.
- michael_h 13y ago
  Didn't Iran get a valid SSL certificate for *.google.com a while ago? Edit: Found an article, by cperciva no less: http://www.daemonology.net/blog/2011-09-01-Iran-forged-the-wrong-SSL-certificate.html http://www.daemonology.net/blog/2011-09-01-Iran-forged-the-w...

loumf 13y ago

Can you explain what this means exactly: "I'll navigate to any URL you send me while logged into the site." If I give you a URL what exactly are you going to do? Also, when logged into the site, are you logged into the account where the note with claim instructions was made?

absherwin 13y ago
I'll paste it into another tab in a browser that has me logged into the account or I'll log into the account after pasting the link. Whichever you prefer. If you have another proposal, as long as it's something reasonable, I'm happy to entertain it.

nicksdjohnson 13y ago

tl;dr: You've set up the challenge in such a way that demonstrating any of the threat models against which client side crypto is weak would require compromising other layers of security first that are out of scope for the challenge.