[liberationtech] Passlok's broken security model

[Steve Weis]

Hi Francisco. I split this off into a new thread, since it touches on some
points on why the security model for Passlok is broken.

Comments inline...

On Tue, Aug 13, 2013 at 2:54 PM, Francisco Ruiz <ruiz at iit.edu> wrote:
>
> 1. Unicode: wget returned escaped Unicode characters. Chrome saved output
>> containing actual Unicode characters. Your suggested method of cutting from
>> view-source and pasting into a text editor may be unpredictable, and
>> dependent on a user's OS and locale.
>>
>
> I think the Unicode characters got in when I added the qr.js code, which
> had comments  in Korean ;-) Do you think it's maybe best to get rid of
> anything that is not strict ASCII? The code doesn't need any special
> characters.
>

No, there are other Unicode characters in the document, e.g. U+25BC.
Manually removing these characters isn't going to help you.

I changed my browser's default encoding. That changes the charset in the
html tag, as well as some characters in the body. I tried UTF-8, Arabic,
and Chinese encodings and they all saved with slightly different data,
which will all fail to verify with your single hash value.

Chrome ships with like 30 different supported encodings and each browser
may handle this differently, so there are many potential hash values from
your page.

I've spent a lot of time making the code run nice and polishing the user
> interface. I didn't suspect code validation was going to be this difficult.
> Truth is, most users are never going to bother with validating the code,
> but a few will care intensely about this.
>

If users have to trust the code that is served every time they visit
Passlok, then users have to trust you and your hosting provider Site44
entirely. If Site44 were compromised or subpoenaed, you may not even know
about it.

You suggested users download the Passlok page, validate it themselves, and
run their local copy. Now you say that nobody is going to bother, which
means we're back to the security model of trusting you and your hosting
provider entirely.


> Ah, you saw that. It's the elliptic curve output. SJCL handles points and
> exponents as complex recursive objects. In order to display them for the
> user, I extract the data and convert it into base64. For reasons that I
> don't fully understand (probably having to do with 521, the true bit length
> of the elliptic curve numbers, not being divisible by 6), those strings
> always start with "A". Since I intensely dislike displaying supposedly
> random-looking strings that always begin with the same character, I strip
> it, but instruct the functions that read those strings from the interface
> to add it again before they do any calculations.
>

You admit you don't understanding what's going on with the encoding, but
decided to intentionally corrupt an encoded key value because you didn't
like a string looking non-random? The consequence is that you added
unnecessary code complexity to fix the key value every time you want to use
it.

Did you change any other part of the crypto implementation based on
aesthetics?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20130813/e3528381/attachment.html>