[Design] On encrypting passwords

[Grant Baillie]

On 22 Mar, 2007, at 09:54, Mimi Yin wrote:

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

Hey, Mimi

Non-Apple apps do use the OS keychain (Colloquy, SSHKeychain are 2 I  
use all the time).

Long-term, I'd say that's what we want Chandler to do. I believe the  
barrier is engineering time:

- For Linux, I don't think there's a standard service like this, so  
we have to roll a complete implementation anyway (i.e. as
Heikki has done).

- For the Mac, the OS keychain APIs aren't available from standard  
Python, so there's work involved in making them available. Also, if  
you adopt platform-dependent solutions, there's work involved in  
making sure the right platforms call the right code.

- I'm not sure what the story is for Windows. I'd be surprised if  
there wasn't a standard password encryption service, but I haven't  
researched that.

--Grant

> 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
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design