nal Message
From: "mhey...@gmail.com"
Sent: Thu Jan 05 08:10:57 EST 2012
To: Landon
Cc: cryptography@randombit.net
Subject: Re: [cryptography] Password non-similarity?
On Sat, Dec 31, 2011 at 5:02 PM, Landon wrote:
>
> A lot of the password reuse is simply adding +1 or
On Sat, Dec 31, 2011 at 5:02 PM, Landon wrote:
>
> A lot of the password reuse is simply adding +1 or something on
> the end. Since the base of the password stays the same, couldn't
> you just hash the first and second halves of the new and old
> passwords separately and compare each pair? (Or any
2012/1/3 Jonathan Katz
> On Mon, 2 Jan 2012, lodewijk andré de la porte wrote:
>
> The reason for regular change is very good. It's that the low-intensity
>> brute forcing of a password requires a certain stretch of time. Put the
>> change interval low enough and you're safer from them.
>>
>> We
On Tue, Jan 3, 2012 at 8:07 PM, wrote:
>
> > So I would conjecture, at least in cases like this where users only
> > login infrequently, that the password change policy every N days
> > be done away with, or at the very least, we make N something
> > reasonably long, like 365 or more days.
>
> So I would conjecture, at least in cases like this where users only
> login infrequently, that the password change policy every N days
> be done away with, or at the very least, we make N something
> reasonably long, like 365 or more days.
Kevin, are you suggesting a "50 uses and change it"
On Tue, 3 Jan 2012, Solar Designer wrote:
On Mon, Jan 02, 2012 at 09:40:36PM -0500, Jonathan Katz wrote:
Say passwords are chosen uniformly from a space of size N. If you never
change your password, then an adversary is guaranteed to guess your
password in N attempts, and in expectation guesses
On Mon, Jan 02, 2012 at 09:40:36PM -0500, Jonathan Katz wrote:
> Say passwords are chosen uniformly from a space of size N. If you never
> change your password, then an adversary is guaranteed to guess your
> password in N attempts, and in expectation guesses your password in N/2
> attempts.
>
On Mon, 2 Jan 2012, lodewijk andr?? de la porte wrote:
The reason for regular change is very good. It's that the low-intensity
brute forcing of a password requires a certain stretch of time. Put the
change interval low enough and you're safer from them.
We've had someone talk on-list about a si
On Mon, Jan 2, 2012 at 7:12 PM, Craig B Agricola wrote:
> On Sun, Jan 01, 2012 at 03:16:39AM -, John Levine wrote:
>> Where's this log? Wherever it is, it's on a system that also has their
>> actual password.
>>
>> If I wanted to reverse engineer passwords, this doesn't strike me as a
>> part
On Sun, Jan 01, 2012 at 03:16:39AM -, John Levine wrote:
> > Well, on more than a few occasions, I've observed cases
> >where users have accidentally entered their password into the
> >"username" field (either alone, or with the username preprended).
> >Of course, the login attempt fails and, m
On 2012/1/2 lodewijk andré de la porte :
> The reason for regular change is very good. It's that the low-intensity
> brute forcing of a password requires a certain stretch of time. Put the
> change interval low enough and you're safer from them.
This may make sense in specific cases, but in the ge
The reason for regular change is very good. It's that the low-intensity
brute forcing of a password requires a certain stretch of time. Put the
change interval low enough and you're safer from them.
We've had someone talk on-list about a significant amount of failed remote
ssh login attempts. Shou
> Bernie Cosell writes:
>> On 31 Dec 2011 at 15:30, Steven Bellovin wrote:
>>> Yes, ideally people would have a separate, strong password, changed
>>> regularly for every site.
>>
>> This is the very question I was asking: *WHY* "changed regularly? What
>> threat/vulnerability is addressed by r
On 2 January 2012 03:01, ianG wrote:
>>> When I was a rough raw teenager doing this, I needed around 2 weeks to
>>> pick up 5 letters from someone typing like he was electrified. The other 3
>>> were crunched in 4 hours on a vax780.
>>
>> how many samples? (distinct shoulder surf events)
>
>
> Ab
On 1/01/12 18:09 PM, coderman wrote:
On Sat, Dec 31, 2011 at 9:36 AM, ianG wrote:
...
When I was a rough raw teenager doing this, I needed around 2 weeks to pick
up 5 letters from someone typing like he was electrified. The other 3 were
crunched in 4 hours on a vax780.
how many samples? (dist
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In message , Kevin W. Wall writes
>Indeed, Ross Anderson did some study of this in one of his
>classes (sorry, I don't have the citation, but Ross, if you're
>listening, feel free to pipe in) and discovered that passwords
>created this way were almos
On Sat, Dec 31, 2011 at 9:36 AM, ianG wrote:
> ...
> When I was a rough raw teenager doing this, I needed around 2 weeks to pick
> up 5 letters from someone typing like he was electrified. The other 3 were
> crunched in 4 hours on a vax780.
how many samples? (distinct shoulder surf events)
2 we
From: Kevin W. Wall
>Or whatever. The misconception is of course, that this
>truly is "best practice". Pretty sure that it's some CYA
>policy along this line that is driving this. And IT has learned
>it's just easy to implement whatever legal requests than to
>argue the rationality of the decisio
On Sat, Dec 31, 2011 at 10:32 PM, Jeffrey Walton wrote:
> On Sat, Dec 31, 2011 at 10:29 PM, Kevin W. Wall
> wrote:
>> On Sat, Dec 31, 2011 at 9:56 PM, Jeffrey Walton wrote:
>>> On Sat, Dec 31, 2011 at 9:05 PM, Kevin W. Wall
>>> wrote:
On Tue, Dec 27, 2011 at 6:12 PM, Steven Bellovin
>>
On Sat, Dec 31, 2011 at 10:24 PM, Randall Webmail wrote:
> From: Kevin W. Wall
>
>>Boy, the latter sounds like advice that a black hat hacker would give someone
>>to
> ensure simple dictionary attacks are successful. Your dog's name? Really???
>
> Beats the usual method of writing it on a Post-
> The most common password is "Password".
There was a time when computer repairmen would come to your
data center to do your systems maintenance for you. They
invariably had a standing password for your, and everybody
else's, gear.
How do I know? The first time I ever experienced a hack was
On Sat, Dec 31, 2011 at 10:29 PM, Kevin W. Wall wrote:
> On Sat, Dec 31, 2011 at 9:56 PM, Jeffrey Walton wrote:
>> On Sat, Dec 31, 2011 at 9:05 PM, Kevin W. Wall
>> wrote:
>>> On Tue, Dec 27, 2011 at 6:12 PM, Steven Bellovin
>>> wrote:
>>> [snip]
[snip]
>
>>> It would give people an oppor
On Sat, Dec 31, 2011 at 9:56 PM, Jeffrey Walton wrote:
> On Sat, Dec 31, 2011 at 9:05 PM, Kevin W. Wall wrote:
>> On Tue, Dec 27, 2011 at 6:12 PM, Steven Bellovin
>> wrote:
>> [snip]
>>> Here's a heretical thought: require people to change their passwords --
>>> and publish the old ones. That
From: Kevin W. Wall
>Boy, the latter sounds like advice that a black hat hacker would give someone
>to
ensure simple dictionary attacks are successful. Your dog's name? Really???
Beats the usual method of writing it on a Post-It note where the janitorial
staff can see.
The current state of "s
>> I finally realized, that's so when the organization gets pwn3d, you
>> won't have used the stolen passwords anywhere else. Or maybe they
>> imagine that if your password is stolen somewhere else, you won't have
>> changed all the passwords at the same time.
>
>Really? So you're proposing *cros
> Well, on more than a few occasions, I've observed cases
>where users have accidentally entered their password into the
>"username" field (either alone, or with the username preprended).
>Of course, the login attempt fails and, more to the point, the
>invalid "user name" is logged. The users almos
If I can get a list of user names, then it is more efficient
for me to pick a really common password and iterate across
user names. Not helpful to the attacker aiming for a named
target, but likely to work pretty well in, say, the universe
of Facebook names, and I don't trigger 3-strikes-and-you'
On Sat, Dec 31, 2011 at 9:05 PM, Kevin W. Wall wrote:
> On Tue, Dec 27, 2011 at 6:12 PM, Steven Bellovin wrote:
> [snip]
>> Here's a heretical thought: require people to change their passwords --
>> and publish the old ones. That might even be a good idea...
>
> I'm not sure if you were just bei
On Sat, Dec 31, 2011 at 9:02 PM, Bernie Cosell wrote:
> On 1 Jan 2012 at 11:02, Peter Gutmann wrote:
>
>> Bernie Cosell writes:
>> >On 31 Dec 2011 at 15:30, Steven Bellovin wrote:
>> >> Yes, ideally people would have a separate, strong password, changed
>> >> regularly for every site.
>> >
>> >Th
On Tue, Dec 27, 2011 at 6:12 PM, Steven Bellovin wrote:
[snip]
> Here's a heretical thought: require people to change their passwords --
> and publish the old ones. That might even be a good idea...
I'm not sure if you were just being facetious here or if you were serious, but
you know, I think
On 1 Jan 2012 at 11:02, Peter Gutmann wrote:
> Bernie Cosell writes:
> >On 31 Dec 2011 at 15:30, Steven Bellovin wrote:
> >> Yes, ideally people would have a separate, strong password, changed
> >> regularly for every site.
> >
> >This is the very question I was asking: *WHY* "changed regularly?
On 31 Dec 2011 at 16:59, Steven Bellovin wrote:
> On Dec 31, 2011, at 4:36 00PM, Bernie Cosell wrote:
>
> > On 31 Dec 2011 at 15:30, Steven Bellovin wrote:
> >
> >> Yes, ideally people would have a separate, strong password, changed
> >> regularly for every site.
> >
> > This is the very questi
On 31 Dec 2011 at 21:44, John Levine wrote:
> >This is the very question I was asking: *WHY* "changed regularly? What
> >threat/vulnerability is addressed by regularly changing your password?
>
> I finally realized, that's so when the organization gets pwn3d, you
> won't have used the stolen pa
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512
A lot of the password
reuse is simply adding +1 or something on the end. Since the base of
the password stays the same, couldn't you just hash the first and
second halves of the new and old passwords separately and compare each
pair? (Or any arbitrar
On Dec 31, 2011, at 5:09 08PM, John Levine wrote:
>> The standard rationale is that for any given time interval, there's a
>> non-zero probability that a given password has been compromised. At
>> some point, the probability is high enough that it's a real risk.
>
> Sure, but where does that pr
>The standard rationale is that for any given time interval, there's a
>non-zero probability that a given password has been compromised. At
>some point, the probability is high enough that it's a real risk.
Sure, but where does that probability come from? (Various tactless
anatomical guesses eli
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 A lot of the password reuse is
simply adding +1 or something on the end. Since the base of the password stays
the same, couldn't you just hash the first and second halves of the new and old
passwords separately and compare each pair? (Or any arbitr
Bernie Cosell writes:
>On 31 Dec 2011 at 15:30, Steven Bellovin wrote:
>> Yes, ideally people would have a separate, strong password, changed
>> regularly for every site.
>
>This is the very question I was asking: *WHY* "changed regularly? What
>threat/vulnerability is addressed by regularly cha
On Dec 31, 2011, at 4:36 00PM, Bernie Cosell wrote:
> On 31 Dec 2011 at 15:30, Steven Bellovin wrote:
>
>> Yes, ideally people would have a separate, strong password, changed
>> regularly for every site.
>
> This is the very question I was asking: *WHY* "changed regularly? What
> threat/vulne
On Sat, Dec 31, 2011 at 4:44 PM, John Levine wrote:
>>This is the very question I was asking: *WHY* "changed regularly? What
>>threat/vulnerability is addressed by regularly changing your password?
>
> I finally realized, that's so when the organization gets pwn3d, you
> won't have used the stole
>This is the very question I was asking: *WHY* "changed regularly? What
>threat/vulnerability is addressed by regularly changing your password?
I finally realized, that's so when the organization gets pwn3d, you
won't have used the stolen passwords anywhere else. Or maybe they
imagine that if y
>Passwords aren't dead, and despite what IBM says I don't think they're
>going away any time soon. But we need new rules and new guidelines
>for managing them; the ones from the 1980s don't work anymore.
Yeah. At this point the issues seem to be, in no particular order:
1. Trivially guessable p
On 31 Dec 2011 at 15:30, Steven Bellovin wrote:
> Yes, ideally people would have a separate, strong password, changed
> regularly for every site.
This is the very question I was asking: *WHY* "changed regularly? What
threat/vulnerability is addressed by regularly changing your password? I
kno
On Dec 31, 2011, at 12:32 06PM, John Levine wrote:
>>> You can't force people to invent and memorize an endless stream of
>>> unrelated strong passwords.
>>
>> I'm not sure I agree with this phrasing. It is easy to memorize a strong
>> password -- it just has to be long enough.
>
> Don't for
On 1/01/12 03:02 AM, Bernie Cosell wrote:
So what problem _is_ being addressed by requiring passwords to be
changed so often [and so inconveniently]?
As far as I can tell, a lot of password threat modelling was pretty much
settled in the days before the Internet. In those days, the threats
w
>> You can't force people to invent and memorize an endless stream of
>> unrelated strong passwords.
>
>I'm not sure I agree with this phrasing. It is easy to memorize a strong
>password -- it just has to be long enough.
Don't forget "endless stream of unrelated". I have some strong
passwords
On 31 Dec 2011 at 15:17, John Levine wrote:
> You can't force people to invent and memorize an endless stream of
> unrelated strong passwords.
I'm not sure I agree with this phrasing. It is easy to memorize a strong
password -- it just has to be long enough. The problem as I see it is
that wa
>>Has anyone ever implemented a system to enforce non-similarity business rules?
Sure. Every month, the first time a user logs in generate a new
random password, show it to him, and tell him to write it down.
You can't force people to invent and memorize an endless stream of
unrelated strong pas
On Fri, Dec 30, 2011 at 8:40 PM, Randall Webmail wrote:
> On Tue, 27 Dec 2011 15:54:35 -0500 (EST), Jeffrey Walton
> wrote:
>>Hi All,
>>
>>We're bouncing around ways to enforce non-similarity in passwords over
>> time: password1 is too similar too password2 (and similar to
>> password3, etc).
>
From: Jeffrey Walton
To: Randombit List
Sent: Tue, 27 Dec 2011 15:54:35 -0500 (EST)
Subject: [cryptography] Password non-similarity?
>Hi All,
>We're bouncing around ways to enforce non-similarity in passwords over
time: password1 is too similar too password2 (and similar to
pas
On 28/12/11 09:48 AM, Solar Designer wrote:
On Tue, Dec 27, 2011 at 03:54:35PM -0500, Jeffrey Walton wrote:
We're bouncing around ways to enforce non-similarity in passwords over
time: password1 is too similar too password2 (and similar to
password3, etc).
I'm not sure its possible with one way
On Dec 27, 2011, at 5:48 PM, Solar Designer wrote:
> On Tue, Dec 27, 2011 at 03:54:35PM -0500, Jeffrey Walton wrote:
>> We're bouncing around ways to enforce non-similarity in passwords over
>> time: password1 is too similar too password2 (and similar to
>> password3, etc).
>>
>> I'm not sure it
On Dec 27, 2011, at 12:54 PM, Jeffrey Walton wrote:
> Hi All,
>
> We're bouncing around ways to enforce non-similarity in passwords over
> time: password1 is too similar too password2 (and similar to
> password3, etc).
>
> I'm not sure its possible with one way functions and block cipher residu
On Tue, Dec 27, 2011 at 03:54:35PM -0500, Jeffrey Walton wrote:
> We're bouncing around ways to enforce non-similarity in passwords over
> time: password1 is too similar too password2 (and similar to
> password3, etc).
>
> I'm not sure its possible with one way functions and block cipher residues.
I'm assuming that at password change new password policy evaluation
time you have both, the old and new passwords, in which case you can
use Optimal String Alignment Distance for at least that pair of
passwords. If you have only one password you can try a cookbook of
transformations that users mig
On Tue, Dec 27, 2011 at 4:11 PM, Steven Bellovin wrote:
>> Has anyone ever implemented a system to enforce non-similarity business
>> rules?
Enforcing these rules with any regularity (ie not in response to a
specific known breech) seems like its asking for trouble on the UX
side of things.
> Cr
On Dec 27, 2011, at 3:54 PM, Jeffrey Walton wrote:
> Hi All,
>
> We're bouncing around ways to enforce non-similarity in passwords over
> time: password1 is too similar too password2 (and similar to
> password3, etc).
>
> I'm not sure its possible with one way functions and block cipher residue
Hi All,
We're bouncing around ways to enforce non-similarity in passwords over
time: password1 is too similar too password2 (and similar to
password3, etc).
I'm not sure its possible with one way functions and block cipher residues.
Has anyone ever implemented a system to enforce non-similarity
58 matches
Mail list logo
