Re: blacklisting the bad ssh keys?

2008-05-23 Thread Abe Singer
Ahh the irony, apparently Debian has implement just such a feature,
but as patch to ssh within their distro:

http://www.mail-archive.com/[EMAIL PROTECTED]/msg214853.html


On Thu, May 22, 2008 at 11:19:05AM -0700, Abe Singer wrote:
 
 On Wed, May 14, 2008 at 07:52:58PM -0400, Steven M. Bellovin wrote:
  
  Given the published list of bad ssh keys due to the Debian mistake (see
  http://metasploit.com/users/hdm/tools/debian-openssl/), should sshd be
  updated to contain a blacklist of those keys?  I suspect that a Bloom
  filter would be quite compact and efficient.
 
 As someone who is dealing with this operationally, we (SDSC) had already
 identified what Steve suggests as the desireable long-term solution.
 I would reword the requirement slightly to say that the capability of
 sshd should be to block use of any key specified by the adminstrator,
 not necessarily just the published blacklist.  I think that's what Steve
 may have actually meant, but clarity is helpful.
 
 -
 The Cryptography Mailing List
 Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: blacklisting the bad ssh keys?

2008-05-22 Thread Abe Singer
On Wed, May 14, 2008 at 07:52:58PM -0400, Steven M. Bellovin wrote:
 
 Given the published list of bad ssh keys due to the Debian mistake (see
 http://metasploit.com/users/hdm/tools/debian-openssl/), should sshd be
 updated to contain a blacklist of those keys?  I suspect that a Bloom
 filter would be quite compact and efficient.

As someone who is dealing with this operationally, we (SDSC) had already
identified what Steve suggests as the desireable long-term solution.
I would reword the requirement slightly to say that the capability of
sshd should be to block use of any key specified by the adminstrator,
not necessarily just the published blacklist.  I think that's what Steve
may have actually meant, but clarity is helpful.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Private Key Generation from Passwords/phrases

2007-01-30 Thread Abe Singer
On Sun, Jan 28, 2007 at 11:52:16AM -0500, Steven M. Bellovin wrote:
  
 Is that all in one /etc/passwd file (or the NIS equivalent)?  Or is it a
 Kerberos KDC?  I note that a salt buys the defense much less in a

For SDSC, one file.  For UCSD, not sure, but I suspect it's (now) a KDC.
(Brian, are you on this list?)

 Kerberos environment, where capture of the KDC database lets an
 attacker roam freely, and the salt simply protects other sites where
 users may have used the same password.

Agreed.

 Beyond that, 60K doesn't make that much of a difference even with a
 traditional /etc/passwd file -- it's only an average factor of 15
 reduction in the attacker's workload.  While that's not trivial, it's
 also less than, say,  a one-character increase in average password
 length.  That said, the NetBSD HMAC-SHA1 password hash, where I had
 some input into the design, uses a 32-bit salt, because it's free.


I don't disagree with you.  I was just addressing your implication
(or at least, what I *read* as an implication ;-) that  4096 users
was rare.

FWIW, the glibc MD5 crypt function uses a 48-bit hash.

also FWIW, salt lengths significatly affect  the work factor and storage
requirements for pre-computated hashes from dictionaries.

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]


Re: Interesting bit of a quote

2006-07-12 Thread Abe Singer
On Tue, Jul 11, 2006 at 05:50:06PM -0700, David Wagner wrote:
 
 No, it doesn't.  I think you've got it backwards.  That's not what SB1386
 says.  SB1386 says that if a company conducts business in Caliornia and
 has a system that includes personal information stored in unencrypted from
 and if that company discovers or is notified of a breach of the security
 that system, then the company must notify any California resident whose
 unencrypted personal information was, or is reasonably believed to have
 been, acquired by an unauthorized person. [*]

A small, but very significant correction.  The law says any breach of the 
security of the data, not security of the system.

The more explicit paragraph is in 1798.82(b)

   (b) Any person or business that maintains computerized data that
   includes personal information that the person or business does not
   own shall notify the owner or licensee of the information of any
   breach of the security of the data immediately following discovery,
   if the personal information was, or is reasonably believed to have
   been, acquired by an unauthorized person.


And even though the code has already stated such, it further goes on
to define security of the system in 1798.82(d):

   (d) For purposes of this section, breach of the security of the
   system means unauthorized acquisition of computerized data that
   compromises the security, confidentiality, or integrity of personal
   information maintained by the person or business. [...]

 If you know or are notified that the security of your system has been
 breached and if you know or have some reason to believe that someone
 has received unauthorized access to unencrypted personal information
 about California residents, then sure, you have to act on the presumption
 that the personal information was spilled.  So what?  That seems awfully
 reasonable to me.

reasonable is for a judge or jury to decide.  A lawyer's job is to do
what's the the best interests of the client, and in this circumstance,
make a determination of what will be considered reasonable in court.
And ask three lawyers a question, you'll get at least four opinions. (the
same can be said for security geeks).

But ultimately, what the lawyer is deciding is what's going to cost the
client less: disclosure or possibly penatly of non-disclosure.  They'll
often opt for the former to avoid the possibility high cost of the latter.

I've been on and around the pointy end of this stick (and no,
not any publicized events).  If unauthorized access cannot clearly
be substatiated, it becomes a judgement call, based on a variety of
factors.  Factors might include duration between compromise and discovery
(e.g. they've been on the system so long that we just can't tell anymore),
intruder activities, etc.

 In short, my reading of SB1386 is that companies only have to notify
 customers if (a) they know or are notified of a security breach and
 (b) they know or have reason to believe that this breach led to an
 unauthorized disclosure of personal information.  In other words, SB1386
 treats companies as innocent until there is some reason to believe that
 they are guilty.  I don't know anything about SOX, but I think you've
 mis-characterized SB1386.  Don't tar SB1386 with SOX-feathers.

SB1386 doesn't spell out guilt or innocence.  It just provides a liability
shield for a company who complies with it, and spells out punitive
damages for failing to comply.

A company could make the decision that the penalty for non-disclosure
is less than it would cost otherwise, and choose to keep quiet and hope
for the best.


 [*] This is pretty close to an direct quote from Section 1798.82(a)
 of California law.  See for yourself:
   
 http://info.sen.ca.gov/pub/01-02/bill/sen/sb_1351-1400/sb_1386_bill_20020926_chaptered.html

Better yet, go directly to the California Code (Civil Code Section):

http://www.leginfo.ca.gov/cgi-bin/displaycode?section=civgroup=01001-02000file=1798.80-1798.84

-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]