Re: password safes for mac

2009-07-01 Thread Adam Shostack
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?

2009-07-01 Thread Udhay Shankar N
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

2009-07-01 Thread Perry E. Metzger

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

2009-07-01 Thread Victor Duchovni
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

2009-07-01 Thread Nicolas Williams
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

2009-07-01 Thread Nicolas Williams
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

2009-07-01 Thread Adam Shostack
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

2009-07-01 Thread Adam Shostack
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

2009-07-01 Thread Anne Lynn Wheeler

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

2009-07-01 Thread Perry E. Metzger

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

2009-07-01 Thread Perry E. Metzger

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