The eclectic musings of a bitter software engineer.

Privnote's developers are confused

Sunday July 06, 2008 @ 02:15 PM (PDT)

Privnote is a new web app making the rounds on Digg and other social networking sites. It allows you to post a note at a unique URL which you can then share with someone. The note is deleted once the URL is viewed. It’s a simple premise that, if used for sending love notes or other inconsequential messages, is cute and harmless. However, the developer of Privnote has irresponsibly crossed into dangerous territory by claiming on his blog that Privnote is secure enough to be used for sending “credit card information and root passwords”.

He goes on to claim that not even Privnote’s developers can read your secret notes:

What about the site administrators, you may ask, those ones who always seem to have “full power” over your data. Well, with Privnote, those cannot read your note either. The explanation is a bit more technical, but here it goes: When the note is received by the server, a note ID is created (the same ID you see in the link to read the note). The note contents is then encrypted and saved in the database but (and here’s the magic) the salt to encrypt the note is not the note ID but a hash of the note ID. Hashes “one way” so you cannot go back to the note ID from the hash. So the note gets stored in the DB encrypted with a token that only the person which has the note link can read it. Oh, and we also have web server access logs disabled which makes impossible for any administrator to decrypt the note contents. So, as you can see, the only person who has the key to decrypt it is the one who has the link to the note.

These are the excited hand-wavings of someone who either has a very poor understanding of logic or is maliciously trying to trick people into disclosing sensitive information. Either way, it’s a big red flashing warning that Privnote is a toy and should not be used for anything even remotely sensitive.

According to the developer’s description, each note has a unique id. The contents of the note are encrypted using a salt consisting of a one-way hash of this id. The id is also used in the URL to identify the note. Here’s where the hand-waving comes in: he claims that, since Privnote doesn’t store access logs and can’t see the URLs, they can’t figure out the decryption key and thus can’t decrypt the notes.

Unfortunately, this is nonsense for the following reasons:

  1. If a URL containing only a note id can be used to retrieve a note, then that note id must be stored in the database in order to be used for lookups.
  2. Since the note id is stored in the database, anyone with access to the database and knowledge of the hashing algorithm used can recreate the hash value used to encrypt a note and can then decrypt that note.
  3. The claim that Privnote doesn’t keep access logs is puzzling; why would access logs even matter if the notes are deleted once they’re accessed?

In other words, anyone with access to both the Privnote database (to retrieve note ids and encrypted contents) and the Privnote source code (to know which hashing algorithm is used) has full access to the decrypted contents of any note sent via Privnote, regardless of the developer’s claims.

It’s one thing for someone to provide a service like Privnote and say, “Your notes are secure as long as you trust us.” It’s another thing entirely for them to claim that even they can’t read your notes when, in fact, they can.


Update (July 06, 2008 @ 07:11 PM): The developer has posted a much more detailed followup correcting the mistakes in his original description of Privnote’s security measures.

As it turns out, they are indeed encrypting notes using cleartext note ids and then only storing the hashed id in the database. This ensures that someone in possession of the database cannot recover the note ids and thus cannot decrypt the notes, and is a much better implementation than the one described in the original post. However it still doesn’t guarantee that Privnote’s developers aren’t executing additional code to intercept notes before they’re encrypted.

I have no reason to believe they’re doing this—I get the impression they’re naïve rather than malicious—but as long as they continue to claim that they can’t possibly read the contents of the notes being passed through their system, they’re lying.

Comments

I’ll admit I haven’t spent a lot of time trying to poke holes in this, but I don’t think your point #1, that the note ID has to be in the database, is correct. This is where their hashing algorithm comes in.

Let’s say I write a note, and the note ID is “hello”. Really, “hello” is the key for a symmetric encryption algorithm, so in the database the text of the note is encrypted using “hello” as the key.

Now, instead of using “hello” as the primary key for that row in the database, I use the md5 sum of “hello” as the primary key. Therefore, in the database, I have the md5sum of “hello” and the encrypted text, but nowhere do I have the actual string “hello.” Therefore, I can’t decrypt the note even if I have access to the database, know the hashing algorithm, and know the encryption algorithm.

When a user comes to retrieve the note, they input the “note ID,” which is really the decryption key. Upon entry of the decryption key, the system takes the md5 sum of the note ID/decryption key to determine which row in the database to retrieve. It grabs the cipher text and decrypts it using the note ID in the URL, not anything that was in the database.

Of course, in the end, you’re still just trusting them not to keep a record of the decryption keys, but I think it’s technically feasible to do what they’re saying they’re doing.

Sunday July 06, 2008 @ 04:32 PM (PDT) Posted by Matthew Wilson

...granted, that’s not exactly what their explanation said. But it sounds like that’s what they’re actually going for, so who knows if they just fumbled the explanation or fumbled the actual implementation.

Sunday July 06, 2008 @ 04:39 PM (PDT) Posted by Matthew Wilson

What you’re describing is a simple password-based system, but that’s not what Privnote has implemented. Note ids are dynamically generated, not chosen by users, and according to the developer’s blog entry, “the salt to encrypt the note is not the note ID but a hash of the note ID”.

Whether the note id is stored hashed or in the clear doesn’t matter; either way, the hash of the note id is easily obtainable by anyone with database access, and therefore the note is easily decryptable.

Sunday July 06, 2008 @ 04:46 PM (PDT) Posted by Ryan Grove

I believe what Matthew is suggesting is that the salt is actually the Note ID, not the hash of the Note ID.

With that, it is secure to store the hashed Note ID and the encrypted text. The only way to decrypt it is for a user to access the note with the plaintext Note ID corresponding to the hashed Note ID.

Sunday July 06, 2008 @ 04:49 PM (PDT) Posted by Zain

...

I think that you are the one being plain malicious without fundament. Have you heard about the viacom/youtube case? That is the reason for saying they don´t keep the records,maybe? How is it that you state something like that without the propper info source, do you know how it´s done? really? huh…didn´t think so…

Sunday July 06, 2008 @ 05:12 PM (PDT) Posted by marni

My source was the developer’s own blog post describing Privnote’s security measures. My analysis here is based on the statements made in that post.

Sunday July 06, 2008 @ 06:51 PM (PDT) Posted by Ryan Grove

Hi, I’m that Privnote developer. I just wanted to let you know that I’ve posted a (hopefully better) explanation of how Privnote works here.

Feel free to add a comment there if you have any questions.

Sunday July 06, 2008 @ 07:33 PM (PDT) Posted by Pablo Hoffman

BTW wonko, why did you change your original title of our post from “Privnote developers are either stupid or malicious” to “Privnote’s developers are confused ”; this act only proof that you are confused!

Sunday July 06, 2008 @ 09:10 PM (PDT) Posted by gabriel

I changed the title when Pablo updated his blog post with more information and the old title no longer applied. I also added an additional section to my post indicating the date and time that I posted the update. Nice work, Sherlock.

Sunday July 06, 2008 @ 10:38 PM (PDT) Posted by Ryan Grove

just that or maybe I am confused orsomething…

Monday July 07, 2008 @ 07:00 AM (PDT) Posted by marni

OK

Privnote is just stupid.

Everytime I see privnote, I just PrintScreen

Monday July 07, 2008 @ 07:10 PM (PDT) Posted by est

I am eating delicious custard whilst people bicker about trivial matters that are obsolete in light of the update posted at the end of the article. Yum!

Tuesday July 08, 2008 @ 03:54 AM (PDT) Posted by brunslo
Post a comment

Basic XHTML (including links) is allowed, just don't try anything fishy. Your comment will be auto-formatted unless you use your own <p> tags for formatting. You're also welcome to use Textile.

Don't type anything here unless you're an evil robot:


And especially don't type anything here:

Copyright © 2002-2008 Ryan Grove. All rights reserved.
Powered by Thoth.