Re: password safes for mac
On Tue, Jun 30, 2009 at 11:26:06AM -0500, Nicolas Williams wrote: | On Mon, Jun 29, 2009 at 11:29:48PM -0700, Jacob Appelbaum wrote: | This would be great if LoginWindow.app didn't store your unencrypted | login and password in memory for your entire session (including screen | lock, suspend to ram and hibernate). | | I keep hearing that Apple will close my bug about this and they keep | delaying. I guess they use the credentials in memory for some things | where they don't want to bother the user (!) but they still want to be | able to elevate privileges. | | Suppose a user's Kerberos credentials are about to expire. What to do? What fraction of mac users are using Kerberos? Adam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: What will happen to your crypto keys when you die?
Udhay Shankar N wrote, [on 5/29/2009 9:02 AM]: Fascinating discussion at boing boing that will probably be of interest to this list. http://www.boingboing.net/2009/05/27/what-will-happen-to.html Followup article by Cory Doctorow: http://www.guardian.co.uk/technology/2009/jun/30/data-protection-internet Udhay -- ((Udhay Shankar N)) ((udhay @ pobox.com)) ((www.digeratus.com)) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: password safes for mac
Adam Shostack a...@homeport.org writes: On Tue, Jun 30, 2009 at 11:26:06AM -0500, Nicolas Williams wrote: | On Mon, Jun 29, 2009 at 11:29:48PM -0700, Jacob Appelbaum wrote: | This would be great if LoginWindow.app didn't store your unencrypted | login and password in memory for your entire session (including screen | lock, suspend to ram and hibernate). | | I keep hearing that Apple will close my bug about this and they keep | delaying. I guess they use the credentials in memory for some things | where they don't want to bother the user (!) but they still want to be | able to elevate privileges. | | Suppose a user's Kerberos credentials are about to expire. What to do? What fraction of mac users are using Kerberos? I think he's pointing out a more general problem. -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: password safes for mac
On Wed, Jul 01, 2009 at 11:03:13AM -0400, Adam Shostack wrote: On Tue, Jun 30, 2009 at 11:26:06AM -0500, Nicolas Williams wrote: | On Mon, Jun 29, 2009 at 11:29:48PM -0700, Jacob Appelbaum wrote: | This would be great if LoginWindow.app didn't store your unencrypted | login and password in memory for your entire session (including screen | lock, suspend to ram and hibernate). | | I keep hearing that Apple will close my bug about this and they keep | delaying. I guess they use the credentials in memory for some things | where they don't want to bother the user (!) but they still want to be | able to elevate privileges. | | Suppose a user's Kerberos credentials are about to expire. What to do? What fraction of mac users are using Kerberos? Spefically, Kerberos to *login* to the system. I use Kerberos on the Mac all the time, but never to login, have not figured out how to make it not get in the way of using the laptop when the KDC is not reachable. Also, I roam between two Realms, office and non-office (used for IMAP and SMTP submission) and neither makes sense as the primary platform login. If I had a stationary desktop Mac at the office, that *would* use Kerberos for login. Still would be in a tiny minority though... -- Viktor. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: password safes for mac
On Wed, Jul 01, 2009 at 12:32:40PM -0400, Perry E. Metzger wrote: I think he's pointing out a more general problem. Indeed. IIRC, the Mac keychain uses your login password as its passphrase by default, which means that to keep your keychain unlocked requires either keeping the password around (bad), keeping the keys in cleartext around (worse?), or prompting for the password/passphrase every time they are needed (unusable). This applies to ssh-agent, the GNOME keychain, etcetera. It also applies to distributed authentication systems with password-based options, like Kerberos. ISTM that keeping the password around (preferably in mlocked memory, and, to be sure, with swap encrypted with ephemeral keys) is probably the better solution. Of course, the keys themselves have to be handled with care too. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: password safes for mac
I should add that a hardware token/smartcard, would be even better, but the same issue arises: keep it logged in, or prompt for the PIN every time it's needed? If you keep it logged in then an attacker who compromises the system will get to use the token, which I bet in practice is only moderately less bad than compromising the keys outright. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: password safes for mac
On Wed, Jul 01, 2009 at 01:06:05PM -0500, Nicolas Williams wrote: | On Wed, Jul 01, 2009 at 12:32:40PM -0400, Perry E. Metzger wrote: | I think he's pointing out a more general problem. | | Indeed. IIRC, the Mac keychain uses your login password as its passphrase | by default, which means that to keep your keychain unlocked requires | either keeping the password around (bad), keeping the keys in cleartext | around (worse?), or prompting for the password/passphrase every time | they are needed (unusable). | | This applies to ssh-agent, the GNOME keychain, etcetera. It also | applies to distributed authentication systems with password-based | options, like Kerberos. As I understand things (and I'm no expert in MacOS internals) LoginWindow is a mandatory process, those others are optional and configurable. I keep keychain and 1password on short leashes, which may not matter at all from the perspective of a sneaky trojan which waits around and then grabs the data, but makes me feel better. Adam #include stddisclaimer.h - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: password safes for mac
On Wed, Jul 01, 2009 at 12:32:40PM -0400, Perry E. Metzger wrote: | | Adam Shostack a...@homeport.org writes: | On Tue, Jun 30, 2009 at 11:26:06AM -0500, Nicolas Williams wrote: | | On Mon, Jun 29, 2009 at 11:29:48PM -0700, Jacob Appelbaum wrote: | | This would be great if LoginWindow.app didn't store your unencrypted | | login and password in memory for your entire session (including screen | | lock, suspend to ram and hibernate). | | | | I keep hearing that Apple will close my bug about this and they keep | | delaying. I guess they use the credentials in memory for some things | | where they don't want to bother the user (!) but they still want to be | | able to elevate privileges. | | | | Suppose a user's Kerberos credentials are about to expire. What to do? | | What fraction of mac users are using Kerberos? | | I think he's pointing out a more general problem. Sure. The problem with general problems is you can't solve them or make tradeoffs around them. You have to delve into each and say what can we do about this? and how much engineering weight should we give this? In the case of Kerberos, I would venture to guess that it's pretty low. In which case, I think Apple might go back to Jake's security issue with LoginWindow, and ask if the Kerberos issue is reason enough to keep the behavior as is. Obviously, there's a tradeoff for Apple here, and Apple has people who have dug into the problem. Those folks may well have good reasons to keep things as they are. From my seat as an Apple customer, I don't understand those reasons, and the example given seems unlikely to be important. So I asked for more detail. Adam (Not speaking for my employer) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: password safes for mac
On 07/01/2009 02:10 PM, Nicolas Williams wrote: I should add that a hardware token/smartcard, would be even better, but the same issue arises: keep it logged in, or prompt for the PIN every time it's needed? If you keep it logged in then an attacker who compromises the system will get to use the token, which I bet in practice is only moderately less bad than compromising the keys outright. Nominally, hardware token is something you have authentication. In many implementations, business rules are added to the chip for stuff like business requirements for multi-factor authentication (like in conjunction with PIN). The resulting situation is business rule/environment specific. In the late 90s, there was work on EU FINREAD standard for external trusted card-acceptor device ... that had trusted pin-entry and trusted display. The objective was countermeasure to lots of well known compromises of PCs (including keylogger ... implying that compromised PC could operate an external hardware token, even if PIN was required per transaction). A lot of this evaporated in the early part of this decade in the wake of with various troubles associated with hardware tokens. As an aside ... one of the things we did in the AADS patent portfolio was to remove business rules from the hardware token ... as part of enabling person centric operation (i.e. the same token might be used for lots of different environments ... as opposed to having hardware token for every unique business environment). An AADS hardware token can support both single-factor as well as multi-factor authentication operation ... but it is up to the business application interacting with the hardware token to indicate the amount of authentication integrity (some assumption about security proportional to risk ... for instance, whether or not PIN might be required for every operation, or at all). -- 40+yrs virtualization experience (since Jan68), online at home since Mar1970 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
AES-256 attacked with time complexity 2^119
Bruce Schneier's coverage: http://www.schneier.com/blog/archives/2009/07/new_attack_on_a.html Paper: https://cryptolux.uni.lu/mediawiki/uploads/1/1a/Aes-192-256.pdf Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
MD6 withdrawn from SHA-3 competition
Also from Bruce Schneier, a report that MD6 was withdrawn from the SHA-3 competition because of performance considerations. http://www.schneier.com/blog/archives/2009/07/md6.html Perry -- Perry E. Metzgerpe...@piermont.com - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com