Re: storing passwords
Re: storing passwords
- Subject: Re: storing passwords
- From: "David A. Feldman" <email@hidden>
- Date: Tue, 24 Dec 2002 13:48:21 -0500
Thanks. To be honest, I'm not sure how strong the security needs to be.
If I were the user, I might be satisfied with my password encrypted via
a mechanism specific to the application but not to the machine. But
that's in part because I'm pretty careful with my files and
permissions. A machine-specific encryption is an intriguing idea,
though, and certainly increases the security.
Ultimately, the security level needs to be strong enough to satisfy the
end user, and of course ultimately that's something I'll have to guess
at, trying to balance difficulty of coding and difficulty of dealing
with the security mechanism for the user with level of security. The
app itself is a straightforward file synchronization app, originally
designed to keep files on two machines (particularly a desktop and a
laptop) in sync. (You can see the app at interfacethis.com/duover.) It
looks like I have users applying it to a wider range of uses than that,
though, including some client/server environments.
--Dave
On Tuesday, December 24, 2002, at 01:25 PM, Michael Latta wrote:
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@hidden
http://InterfaceThis.com
_______________________________________________
cocoa-dev mailing list | email@hidden
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@hidden
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@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.