8 ms·
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
by 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 ago1. 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 ago1. 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 ago1. 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
- AnIrishDuck 13y ago1. A server could silently insert code that replaces your keys with a well known one. Don't kid yourself into thinking anyone would notice this if it was silently tucked away in the minified angular or SJCL code. 2. Your definition of obfuscated and mine clearly differ. I'll be more direct: where's the (well-commented, clearly coded) model/controller code?
- absherwin 13y ago1. Agreed. That's an avenue by which a vulnerability in the server or communication channel could be exploited. 2. It doesn't exist. The code was written in the same form it was uploaded.
- tptacek 13y agoAs you can see upthread, "malicious network" has already been invoked. I think you owe Moxie Marlinspike $1000.