[Design] On encrypting passwords

[Mimi Yin]

Thx Grant...

Do any non-Windows / non-Apple apps use the OS keychain? As in, is  
there a reason we can't use the OS keychain?

Mimi

On Mar 22, 2007, at 9:41 AM, Grant Baillie wrote:

>
> On 22 Mar, 2007, at 09:34, Mimi Yin wrote:
>
>> Hi Heikki,
>>
>> How does this relate to OS keychains? How do Outlook, Apple Mail  
>> and Thunderbird encrypt your passwords? or do they?
>
> I can answer some of these (dunno about Outlook).
>
> - This is unrelated to OS keychains (i.e. doesn't use them in any  
> way).
> - Apple Mail uses the OS keychain for password encryption. So does  
> Safari.
> - Thunderbird has its own password encryption feature. So does  
> Firefox. I don't think the two share any data, but I could be wrong.
>
>
> --Grant
>
>>
>> On Feb 20, 2007, at 3:33 PM, Heikki Toivonen wrote:
>>
>>> Chandler has the ability to remember passwords, and many high  
>>> profile
>>> programs (e.g. Firefox) that have this ability can encrypt these  
>>> passwords.
>>>
>>> Doing encryption/decryption like this traditionally requires the  
>>> user to
>>> set a master password. The master password is never stored on  
>>> disk, it
>>> will be asked from the user on demand, and may be remembered in  
>>> memory
>>> until program shutdown or timeout.
>>>
>>> I think we need to provide some level of encryption support in  
>>> Preview
>>> timeframe. For example, I think our users should be able to  
>>> submit their
>>> repositories to us for debugging purposes without us learning their
>>> passwords.
>>>
>>> Do we want to default to requiring a master password to encrypt and
>>> decrypt the other passwords?
>>>
>>> Or do we start unencrypted, offer a "encrypt" checkbox in the  
>>> accounts
>>> dialog, and also when making a repository backup/dump? (I think I am
>>> slightly in favor of this.)
>>>
>>> Do we want to provide encrypting arbitrary items/attributes? (I  
>>> wouldn't
>>> worry about this until after Preview.)
>>>
>>> Do we want to protect the passwords in memory? I must point out that
>>> this would be quite a bit of work, and it is not certain we could  
>>> even
>>> cover all cases (passing password strings into libraries we may  
>>> not have
>>> control over, for example). This would involve things like: clear  
>>> out
>>> master password on timeout, never store the other passwords in clear
>>> text except for the moment when they are needed, zero out the actual
>>> bits in memory once done, prevent password memory from being swapped
>>> out, etc. (I wouldn't worry about passwords in memory myself.)
>>>
>>> Please note that Chandler already supports encrypting the entire
>>> repository. An alternative on some operating systems is to ask  
>>> the OS to
>>> encrypt the disk/directory where the repository is.
>>>
>>> Another thing to note is that many OSes provide password safes of  
>>> their
>>> own with naturally platform specific APIs. I am not suggesting we  
>>> try to
>>> hook up with these in Preview timeframe.
>>>
>>> Reply-to set to design.
>>>
>>> -- 
>>>   Heikki Toivonen
>>>
>>>
>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>>
>>> Open Source Applications Foundation "Design" mailing list
>>> http://lists.osafoundation.org/mailman/listinfo/design
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Design" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/design
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design