FROM : Michael Latta
DATE : Tue Dec 24 19:25:22 2002
That makes sense. The requirement to run unattended does force your
hand. What other requirements are you operating under? Is the content
sensitive in nature? How tight must the security be? Can you rely on
physical security to the machine? Is the machine it runs on a server
or a client machine? If it is a laptop that might walk you need to be
extra careful. Can the application be tied to the machine it is
installed on?
If you need the strongest security then tie the encryption to the
machine it is running on to ensure it can only be decrypted on that
machine (MAC address of interface, disk sector of the file holding the
key, any other physical characteristics you can come up with). Then
make the file only readable by the user running the application, no one
else. Place that user account in its own group. Give group and world
no permissions. Install the application so al the application files
are owned by this user as well.
Michael
On Tuesday, December 24, 2002, at 10:04 AM, David A. Feldman wrote:
> There are a couple problems with storing in the Keychain. I can't
> understand much of the documentation for it, not I think because I
> lack the programming expertise but because it refers to other
> Mac-specific information for which I can find no documentation, and
> because I don't think it's particularly complete. i have been unable
> to find any way to storing an AppleShare password in the KeyChain
> given the host IP, volume name, username, and password. It appears
> that maybe forving the volume to mount might help but that's not
> ideal, and I'm still not sure how it would work. If someone has
> experience with this and can tell me how to do this, that would be
> very helpful but I've posted to every forum I know without any luck,
> so I'd pretty much given up.
>
> The second problem is that even if I can get the passwords into the
> Keychain, the OS periodically requests permission to unlock it. This
> is a file sync app that has to be able to run unattended on a
> schedule. If every time the user runs Software Update on the OS his
> scheduled synchronizations don't execute because he wasn't there to
> unlock the Keychain for mount_afp, that's a pretty serious problem.
> The only solution I can think of to this is to give the app its own
> internal password storage.
>
> Thanks,
> --Dave
>
> On Tuesday, December 24, 2002, at 12:28 PM, Michael Latta wrote:
>
>> Passwords should be stored in the KeyChain. This allows the user to
>> manage them, clear them, and to reuse them without exposing them to
>> others. A quick search on "KeyChain" in PB produced a large list of
>> information on the subject.
>>
>> - Michael
>>
>> On Tuesday, December 24, 2002, at 07:44 AM, David Rio Vierra wrote:
>>
>>> There is the unix crypt() function for creating DES password hashes.
>>> See 'man 3 crypt' for details. If anyone knows about any better
>>> functions for this purpose, please chime in. You can store the
>>> encrypted password in a file(XML or otherwise), and set its
>>> permissions to octal 400 or equivalent so that only the file's owner
>>> can read it. When your program creates this file, it is usually
>>> owned by the user who launched the process. Of course, this won't
>>> stop an uninformed user from simply giving the file away.
>>>
>>> - Rio
>>>
>>> On Tuesday, December 24, 2002, at 04:47 AM, David A. Feldman wrote:
>>>
>>>> I suppose this is as much a generic development question as a Cocoa
>>>> one, but perhaps someone can help me. I have an app that logs onto
>>>> remote AppleShare servers. I've been having a lot of difficulty
>>>> getting it to work with the Keychain -- and have posted here before
>>>> about that -- but I'm realizing that for unattended operation
>>>> (which is desirable for this app) the Keychain may not be the best
>>>> option anyway, since whenever there's a change to the OS it
>>>> re-requests permission to unlock the Keychain.
>>>>
>>>> I don't have a lot of experience writing security code. So, what
>>>> I'm wondering is this. Is there a way to securely store and
>>>> retrieve users' passwords and save them in the app's data file?
>>>> Some way to encrypt in such a way that my app can decrypt but no
>>>> one else can? Furthermore, the data file is human-readable (and XML
>>>> property list). If encrypted passwords are stored in it, is there
>>>> any way to tighten security further so that someone who gains
>>>> access to the data file can't just go ahead and use the encrypted
>>>> password with a copy of my app to gain access to the remote
>>>> server(s)? And if not, will users see that as a potential security
>>>> hole? Thanks.
>>>>
>>>> --Dave
>>>>
>>>> --------------------------------------------------------------------
>>>> ------
>>>> David A. Feldman
>>>> User Interface Designer
>>>> <email_removed>
>>>> http://InterfaceThis.com
>>>> _______________________________________________
>>>> cocoa-dev mailing list | <email_removed>
>>>> Help/Unsubscribe/Archives:
>>>> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>>>> Do not post admin requests to the list. They will be ignored.
>>> _______________________________________________
>>> cocoa-dev mailing list | <email_removed>
>>> Help/Unsubscribe/Archives:
>>> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>>> Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | <email_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
DATE : Tue Dec 24 19:25:22 2002
That makes sense. The requirement to run unattended does force your
hand. What other requirements are you operating under? Is the content
sensitive in nature? How tight must the security be? Can you rely on
physical security to the machine? Is the machine it runs on a server
or a client machine? If it is a laptop that might walk you need to be
extra careful. Can the application be tied to the machine it is
installed on?
If you need the strongest security then tie the encryption to the
machine it is running on to ensure it can only be decrypted on that
machine (MAC address of interface, disk sector of the file holding the
key, any other physical characteristics you can come up with). Then
make the file only readable by the user running the application, no one
else. Place that user account in its own group. Give group and world
no permissions. Install the application so al the application files
are owned by this user as well.
Michael
On Tuesday, December 24, 2002, at 10:04 AM, David A. Feldman wrote:
> There are a couple problems with storing in the Keychain. I can't
> understand much of the documentation for it, not I think because I
> lack the programming expertise but because it refers to other
> Mac-specific information for which I can find no documentation, and
> because I don't think it's particularly complete. i have been unable
> to find any way to storing an AppleShare password in the KeyChain
> given the host IP, volume name, username, and password. It appears
> that maybe forving the volume to mount might help but that's not
> ideal, and I'm still not sure how it would work. If someone has
> experience with this and can tell me how to do this, that would be
> very helpful but I've posted to every forum I know without any luck,
> so I'd pretty much given up.
>
> The second problem is that even if I can get the passwords into the
> Keychain, the OS periodically requests permission to unlock it. This
> is a file sync app that has to be able to run unattended on a
> schedule. If every time the user runs Software Update on the OS his
> scheduled synchronizations don't execute because he wasn't there to
> unlock the Keychain for mount_afp, that's a pretty serious problem.
> The only solution I can think of to this is to give the app its own
> internal password storage.
>
> Thanks,
> --Dave
>
> On Tuesday, December 24, 2002, at 12:28 PM, Michael Latta wrote:
>
>> Passwords should be stored in the KeyChain. This allows the user to
>> manage them, clear them, and to reuse them without exposing them to
>> others. A quick search on "KeyChain" in PB produced a large list of
>> information on the subject.
>>
>> - Michael
>>
>> On Tuesday, December 24, 2002, at 07:44 AM, David Rio Vierra wrote:
>>
>>> There is the unix crypt() function for creating DES password hashes.
>>> See 'man 3 crypt' for details. If anyone knows about any better
>>> functions for this purpose, please chime in. You can store the
>>> encrypted password in a file(XML or otherwise), and set its
>>> permissions to octal 400 or equivalent so that only the file's owner
>>> can read it. When your program creates this file, it is usually
>>> owned by the user who launched the process. Of course, this won't
>>> stop an uninformed user from simply giving the file away.
>>>
>>> - Rio
>>>
>>> On Tuesday, December 24, 2002, at 04:47 AM, David A. Feldman wrote:
>>>
>>>> I suppose this is as much a generic development question as a Cocoa
>>>> one, but perhaps someone can help me. I have an app that logs onto
>>>> remote AppleShare servers. I've been having a lot of difficulty
>>>> getting it to work with the Keychain -- and have posted here before
>>>> about that -- but I'm realizing that for unattended operation
>>>> (which is desirable for this app) the Keychain may not be the best
>>>> option anyway, since whenever there's a change to the OS it
>>>> re-requests permission to unlock the Keychain.
>>>>
>>>> I don't have a lot of experience writing security code. So, what
>>>> I'm wondering is this. Is there a way to securely store and
>>>> retrieve users' passwords and save them in the app's data file?
>>>> Some way to encrypt in such a way that my app can decrypt but no
>>>> one else can? Furthermore, the data file is human-readable (and XML
>>>> property list). If encrypted passwords are stored in it, is there
>>>> any way to tighten security further so that someone who gains
>>>> access to the data file can't just go ahead and use the encrypted
>>>> password with a copy of my app to gain access to the remote
>>>> server(s)? And if not, will users see that as a potential security
>>>> hole? Thanks.
>>>>
>>>> --Dave
>>>>
>>>> --------------------------------------------------------------------
>>>> ------
>>>> David A. Feldman
>>>> User Interface Designer
>>>> <email_removed>
>>>> http://InterfaceThis.com
>>>> _______________________________________________
>>>> cocoa-dev mailing list | <email_removed>
>>>> Help/Unsubscribe/Archives:
>>>> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>>>> Do not post admin requests to the list. They will be ignored.
>>> _______________________________________________
>>> cocoa-dev mailing list | <email_removed>
>>> Help/Unsubscribe/Archives:
>>> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>>> Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | <email_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
| Related mails | Author | Date |
|---|---|---|
| David A. Feldman | Dec 24, 15:47 | |
| David Rio Vierra | Dec 24, 16:44 | |
| Michael Latta | Dec 24, 18:28 | |
| David A. Feldman | Dec 24, 19:04 | |
| Dan Sugalski | Dec 24, 19:18 | |
| Michael Latta | Dec 24, 19:25 | |
| David A. Feldman | Dec 24, 19:48 | |
| Chris Hanson | Dec 24, 23:43 | |
| Charles Srstka | Jan 5, 20:06 |






Cocoa mail archive

