[liberationtech] Passlok's broken security model

[Francisco Ruiz]

Hi Steve,

Some answers inline below, and thanks for taking all this time to help me.



> 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.
>

So I guess I'd better leave it as UTF-8, which hopefully covers a lot of
users.


>
> 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.
>
>
I guess not, but I'm only using site44 for the time being because it's
free. I'm also changing the code with some frequency. In a more final
installation, I'll have my own server. Perhaps you can recommend a shared
https server that can be trusted?


> 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.
>

Most people aren't going to bother. Correct me if I'm wrong. For them, all
I can do is deliver the code with the greatest possible security. I guess
that means https or one of the fancier methods that some folks at libtech
are recommending, plus a server that won't be hacked/coerced easily.

The whole validation rigmarole is for those relatively few who might not be
so sure that SSL was secure and the server had not problems. Maybe they
want to save their copy of the code in a safe place of their choosing.


>
>
>> 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.
>

I think "corrupt" is a bit strong of a word. The SJCL ECC routines always
spit out an "A" at the start of those base64 strings, perhaps because it is
not really a part of the number represented by the string but an artifact
caused by the encoding they use. If I had written those routines, they
wouldn't be doing that, but I chose to use well-known code so the combined
source is easier to audit.

Perhaps it would have been more "honest" to let that initial "A" be
displayed for the user to see, but in the end I thought it would be raising
unnecessary concerns ("what!, wasn't this supposed to be random?") and took
it out of the displayed strings, and put it back whenever it is needed,
before doing any calculation. All of this is amply documented by comments
in the source code.


>
> Did you change any other part of the crypto implementation based on
> aesthetics?
>
>
That's it for aesthetics. The crypto primaries aren't really affected, only
the display on the screen. There's a lot of aesthetic considerations on the
UI itself, since I wanted it to look good without any graphics, both on
mobile and PC.

Thanks for all your attention, Steve.


> --
> Liberationtech is a public list whose archives are searchable on Google.
> Violations of list guidelines will get you moderated:
> https://mailman.stanford.edu/mailman/listinfo/liberationtech.
> Unsubscribe, change to digest, or change password by emailing moderator at
> companys at stanford.edu.
>



-- 
Francisco Ruiz
Associate Professor
MMAE department
Illinois Institute of Technology

PL13lok=WsH3zTgZn8V3hnIqjdbfPus+5YF5n+LBRPuH9USMMp8izPv+hsLoZKv+jaCFMapJFfiA11Q9yJU1K1Wo0TbjXK/=PL13lok

get the PassLok privacy app at: http://passlok.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20130814/4080dc1a/attachment.html>