Re: SScrypto framework
Re: SScrypto framework
- Subject: Re: SScrypto framework
- From: Stephen Hoffman <email@hidden>
- Date: Wed, 13 Feb 2008 12:09:54 -0500
- Organization: HoffmanLabs LLC
On Wed, 13 Feb 2008 08:08:12 -0800 Jens Alfke wrote:
Maybe there's a better way to do what you want. Looks like you're
trying to store a user's password safely — the best way to do this is
by using the Keychain, which is (among other things) a secure
encrypted password store.
Safest is to not store the password. At all.
Second safest is to store a one-way (non-reversible, cryptographic) hash
(digest). SHA-1 or otherwise, and with associated data (the user and
some other known but varying data) incorporated into the input to reduce
the exposure to rainbow table attacks. Compare the password by hashing
the new and comparing it against the saved hash. But don't ever save the
cleartext password, For the semi-paranoid, erase any buffers that have
held the cleartext.
Somewhere around third place is encryption (reversible), and preferably
to use somebody else's scheme and storage. Somebody that's actually
looked at how to do this securely and implemented same, and Keychain
Services and its storage (or CDSA and LDAP et al) would be the choice in
many Mac OS X environments.
Fourth place is rolling your own password handling. It's not
particularly difficult to do this entirely correctly, but the
implementations can be fussy; it is very easy to get this wrong -- and
"wrong" here includes ending up on the wrong end of a product security
notification or a dictionary attack, for instance.
Reversible storage schemes are comparatively undesirable with passwords.
That's better than cleartext storage. If you don't have the password
(which is where a good one-way hash algorithm leaves you), then you
cannot expose the password. And you can't get blamed for exposing data
you don't have.
The posted SScrypto example uses MD5 as its digest, and that's known to
be vulnerable to attack. (I didn't investigate further to see if other
digests are available.)
If you haven't already seen it, there's an intro to and subsequent links
to the Apple APIs starting here:
http://developer.apple.com/documentation/Security/Conceptual/Security_Overview/Architecture/chapter_2_section_7.html
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden