Hacker News new | ask | show | jobs
by nikcub 3397 days ago
> Next time I won't post in a rush during work hours.

I'd suggest taking the same approach with your "secure, end-to-end encrypted communications" app you keep mentioning here[0]

A one-way sha256 hash of a message using a password that has to be 8 characters long[1] and can't accept special characters[2] is not a secure communications app

It is trivial to find the plaintext in these situations.

Your Chrome extension has a very elementary RCI bug in it[3], which because of your extensions broad permissions[4] profile means anyone with your extension installed can have any code executed by visiting any page.

To release (excuse me) crap like this on one hand while FUD'ing Google's security practices on HN on the other requires a level of hubris that I don't think i've ever previously encountered.

[0] https://www.gibberit.com/

[1] http://i.imgur.com/CsgOkZ2.png

[2] http://i.imgur.com/uZg0E4l.png

[3] http://i.imgur.com/eq19mET.png

[4] http://i.imgur.com/lOsibBP.png

2 comments

Could you explain how [3] is an RCI bug? getNum() returns either 'false' or 'n' with the length of gibberText (ie. n20, n35, etc). I can't imagine any content where .length() would return harmful code; though I'm not well versed in JS.
I'm also interested to know.

Believe it or not, I would love to get Nik as a consultant. I fear my 'hubris' (I won't deny it, this idea is extraordinarily ambitious and I have to be arrogant to even conceive of it) will have pissed him off irrevocably.

That aside, I don't really follow his point on the login PW. I understand 8 char alphanum pw is pretty low entropy... but that isn't used for encryption. And the login attempt rate is pretty strictly rate limited.

And yes, I am getting professionals - not me - to do the heavy lifting. I wrote the proof of concept. I am in no way surprised to find it has issues - I am aware of a few others myself.

It isn't the login password but the message password - although using sha256 for a login password isn't great either

if you're doing

aes(plaintext, sha2(password)) = cyphertext

given cyphertext I can get to plaintext with sha2(8-char dictionary)

well designed systems will generate a truly random key there, exchanged using public-key. if you're going to use a password, you need a key-derivation algorithm

this is all bunk tho since the big vulnerability here is that you're delivering the encryption routines via javascript in a global browser space

> this is all bunk tho since the big vulnerability here is that you're delivering the encryption routines via javascript in a global browser space

So what about mailvelope?

Nm, I understand your point, and yes, no contest. The extension is being broken up and will communicate with the environment on the tab with sent messages, rather than just injecting the whole content script. I hear your point loud and clear.
You're not taking your own advice from two comments up :)
That image isn't very useful on its own.

the design of the app is that it injects content scripts with global variable names everywhere.

any site can overwrite the encryption functions, or redefine some of the global vars that are used for images, etc.

Believe it or not, I very much appreciate your feedback.
I'd probably take the site down, or mark it clearly as being a hobby project.

As for Chrome - that team has some of the smartest infosec and cryptography people in the world working on and contributing to the project. If you want some insight into how some of the security design principals and tradeoffs were rationalized, i'd start with the project wiki:

https://www.chromium.org/Home/chromium-security

It's currently marked as beta all over the site, for exactly these reasons.
it is more prominently marked as "secure, end-to-end encrypted communications" - which it certainly is not.

it is also being marketed as such by you here

You can check again - I have changed the language. That was improper and thanks for the feedback.