[Freeipa-devel] [PATCH] 736-740 webui: various minor fixes

[Endi Sukma Dewata]

On 8/22/2014 12:18 PM, Petr Vobornik wrote:
> On 22.8.2014 17:51, Simo Sorce wrote:
>> On Fri, 2014-08-22 at 09:52 -0500, Endi Sukma Dewata wrote:
>>> On 8/21/2014 7:18 AM, Simo Sorce wrote:
>>>> On Thu, 2014-08-21 at 14:11 +0200, Petr Vobornik wrote:
>>>>> On 13.8.2014 17:20, Endi Sukma Dewata wrote:
>>>>>> 2. Can the UI parse the new key and display it the same way as other
>>>>>> keys that are already saved? That will make it more seamless.
>>>>> Would be nice, but is it worth the effort? We would have to
>>>>> reimplement ipapython.ssh into JavaScript + pull in crypto.js or 
>>>>> other
>>>>> lib for sha1and sha256 functions since Web Cryptography API is still
>>>>> only a draft [1].
>>>> I do not do this lightly, but you have my veto to do any crypto in
>>>> javascript unless you convince me first it make sense.
>>>>
>>>> Simo.
>>>
>>> Just to clarify, the point is to display some kind of information about
>>> the public keys the user just entered in the UI (that have not been
>>> saved) so that:
>>> a) If user enters multiple keys at once, the user can distinguish which
>>> keys have been added rather than displaying a generic "New: key set" 
>>> for
>>> all new keys.
>>> b) The UI can detect if the key already exists on the server.
>>> If this can be done without any cryptographic operations that would be
>>> great, but I'm not sure about the details.
>>>
>>> For (a) I was wondering if the UI can decode the base-64 encoded public
>>> key entered by the user and display some user-friendly information 
>>> about
>>> the key itself, maybe just the hexdump of the first few bytes of the
>>> key, or maybe the key type too if possible, or at least just the first
>>> few chars of the undecoded key.
>>>
>>> For (b) the UI would have to use some crypto functions to generate the
>>> key fingerprints as generated by the server. But even if we do that, we
>>> are not doing any data encryption or dealing with secret information.
>>
>> I do not think you need crypto functions for (a) and it is unclear to me
>> what (b) is, if the key already exist on the IPA server you can find it
>> out with a simple memcmp, why should you need a fingeprint ?
>
> in both (a) and (b) the key does not exist on the server - user just 
> added the key(s) but he had not yet clicked on 'update' button to 
> upload them.
>

Right, all the UI has is the base-64 encoded key entered by the user. So 
without crypto, all the UI can do is probably decoding the key and, if 
possible, parsing the key structure to obtain some useful information. 
Can we obtain the key type this way, or does it require crypto?

The existing keys on the other hand are displayed in the UI with their 
fingerprints and key type, for example:
   A8:50:ED:5A:8A:78:81:8D:B9:34:CC:99:D4:6A:E1:32 (ssh-rsa)
The UI does not show the base-64 encoded key unless the user clicks the 
"Show/Set key" button.

To check if a new key already exists on the server, the UI can compare 
either the base-64 encoded keys or the fingerprints (if available).

> Will displaying of the fingerprints prior saving help(improve UX) the 
> user? The issue is that user can't distinguish multiple added keys. 
> The "first few chars of the undecoded key" variant of (a) will solve 
> the issue in the most efficient way - user will see what he just 
> added. No crypto needed.

Displaying the fingerprints of the new keys is not necessary to solve 
(a), but the display will not be seamless without it. For example, it 
could become like this:

   A8:50:ED:5A:8A:78:81:8D:B9:34:CC:99:D4:6A:E1:32 (ssh-rsa)
   AAAAB3NzaC1yc2EAAAABIwAAAQEAueevoxw+... (new key)

On the other hand, since existing keys are displayed with their 
fingerprints, it's not possible to open a public key file and compare it 
to the list before adding it to the UI.

Are the fingerprints actually only used internally by the server? Do the 
users have any use of the fingerprints? If the fingerprints are internal 
only, the UI shouldn't need to display it. I'd say the UI should just 
display the key itself, not the whole key but just long enough to be 
distinguishable, either as a hexdump or base-64 encoded.

>>
>>> BTW, WebCrypto implementation has been making its way into Firefox:
>>> https://docs.google.com/spreadsheet/ccc?key=0AiAcidBZRLxndE9LWEs2R1oxZ0xidUVoU3FQbFFobkE&usp=sharing 
>>>
>>
>> Yes and I find it a particularly bad/dangerous thing, I tend to agree
>> with this: http://tonyarcieri.com/whats-wrong-with-webcrypto see also
>> the links it points to which explains why crypto in javascript (ie in
>> the "user-hostile" sandbox running in the browser) is mostly a bad idea,
>> and can give a false sense of security and a slippery slope in actually
>> unprotecting data.
>>
>> Simo.
>>

If for some reason we decided to generate fingerprints in the UI, in my 
opinion using WebCrypto will not pose any security problem or mislead 
users into a false sense of security because the operation is purely 
informational, it does not do any encryption/decryption/validation. Any 
fingerprint generated on the UI side will be discarded anyway, the 
server will still generate its own fingerprints.

This belongs to a separate discussion, but the article was concerned 
about possible inconsistencies across browser implementations and the 
reliance on the server to deliver the application that uses WebCrypto. I 
think there are limited/specific scenarios where WebCrypto could be used 
in IPA (like above) as long as the implications are well understood. In 
the future we might be able to deliver the whole UI as a signed browser 
extension that uses WebCrypto which would address those concerns.

-- 
Endi S. Dewata