 | | | | | | |
| |
|
In lugnet.admin.general, Todd Lehman writes:
> Specific personal questions:
>
> 1. How would you feel (better or worse) if the numeric values of the ratings
> were not displayed to you unless you specifically requested (via some simple
> setting) that they be displayed to you?
Better
> 2. How would you feel (better or worse) if the numeric values of the ratings
> were not displayed ever to anyone but collected and used by the server only
> for internal calculations, hotlist generation, and personal recommendations
> to you?
So so. If the feature is to be kept, prefer that they be viewable. Else why
have them.
> 3. How would you feel (better or worse) if the ratings were not even
> collected and collated in the first place? (i.e. the destruction of the
> feature altogether)
Better. Wish the time had never been spent to develop them.
> 4. Have you ever felt victimized by the rating system? Have you posted
> something which has obtained a low rating and felt uncomfortable or unhappy
> about yourself or about LUGNET because of the low rating? How often?
Victimized? Hardly.
Annoyed that there's a strategic rater out there (and while there is no way to
PROVE it, I have pretty strong circumstantial evidence that it happens to me on
a fairly regular basis, and I am starting to suspect I know who it is, which
just validates my opinion of that person as basicaly a waste of food) but I
don't really seek validation from others as my main goal in posting, so I don't
get "unhappy about myself" over it. If you, gentle reader, do... grow up!
But then I am more self assured than the average person and I truly believe
that other people may well not have strong enough egos to get "down checked"
(or apparently downchecked... as I said, no amount of explaining away will
correct the perception that downchecking is what is happening) without feeling
bad about it.
> 5. Have you ever felt victimized indirectly by seeing someone else's post
> get a high rating? How often?
No one makes better posts than me (when I take the time to be eloquent) so how
could I be upset by someone else getting a good rating? That's saying that a
competent person is threatened by another persons competence. If I believed
that I would be threatened by the ability of others to make models almost as
good as mine or to architect systems almost as well as, or even better than, I
do. That way lies Looterville of the soul. So no.
Further I'd say that anyone who feels victimised because someone else was
winning a popularity contest this meaningless in the grand scheme of things has
deep deep issues and may want to seek professional help.
> 6. Do you feel that the article rating system makes it easier for you or
> harder for you to share your ideas? And does this bother you?
Mildly easier when they are good ideas, harder when they're flippant fluff, so
that's a (tiny little) good thing.
> 7. How does your initial reaction to the announcement of the article rating
> system compare to your current opinion of it?
Initially thought it was technically a neat idea and wasn't sure of the social
implications. Early experiences I observed portended problems which came to
pass.
Now feel that the LDT (Lugnet Development Time) would have been better spent on
any number of other things, such as unifying member information/cookies, fixing
the ***broken*** password system, streamlining and improving set database input
capabilities, allowing member areas to be created, facilitating group
sheparding/information gathering, improving the web interface ability to
remember what you had read, or some other things that I forget.
But then LDT gets spent on weird things. Look at how much of it was spent on a
password checker that over time due to repeated twiddling became so tuned to
recognise arcane substitutions that it fails perfectly good random passwords
that are not subject to dictionary attack... and ultimately there that checker
sits, a neat toy to play with, and we still have broken hard to remember
passwords that we can't change. But LDT is Todd's to spend as he sees fit. As
it should be.
Ratings have been a big administrative waste of time so far. Time that I'd
rather see Todd spend on coding useful features or on building or on sleeping,
or on having fun with Suz. Or even on doing LDT for geeky, useless but less
divisive things like that password checker.
> 8. Do you feel that it is too early, too late, or the right time to address
> these issues?
A bit late... quite a bit. The right time would have been before they were
deployed, and before this brouhaha got out of hand.
> 9. What other areas (besides news articles) can you imagine that a
> collaborative ratings system would be most helpful to you? LEGO sets?
> Websites? Individual web pages? etc...
Websites. I already know what sets I like and don't need anyone else's opinion,
thank you very much, but I don't know about all the websites out there and do
value some filtering there. Make it like Amazon in that it shows me sites I am
likely to like based on how I rated sites myself, not just ones that the great
unwashed masses liked, because who cares about popularity.
One other comment.... the current linear rating system, no matter how the
number of gradations, starting point, scale values, etc, is tuned, is
insufficient. That's because it is linear. As with so many things, there are
more dimensions than just one.
on/off topicness
newsworthiness
long term information value
Gee whiz that's neat factor
suitability for children
Just to name a few possible things...
Pretty much any linear scale is broken, c.f. the right left "political
spectrum" which fails to describe anything useful because politics is not one
dimensional.
> Thanks for your time
No charge. I just wrapped up a project early and sold followon work, so I'm in
a good mood.
++Lar
| | | | | | | | | | | | | | | |
| |
|
In lugnet.admin.general, Larry Pieniazek writes:
> [...]
> But then LDT gets spent on weird things. Look at how much of it was spent on
> a password checker that over time due to repeated twiddling became so tuned
You talk as if you seem to know how much actual time was spent on it. Elapsed
time is a crude indicator of development time.
> [...]
> Ratings have been a big administrative waste of time so far. Time that I'd
> rather see Todd spend on coding useful features or on building or on
> sleeping, or on having fun with Suz. Or even on doing LDT for geeky, useless
> but less divisive things like that password checker.
Sorry if you feel the password checker is useless. Sorry if you feel inclined
to make gross assumptions about how time is being spent based on what you see
from the outside. We work on many different things at once. If you judge
what's being worked on by what appears as features, you'll get a very warped
view. Some things in the over are 3 years old. Some things are 2 months old.
Some things are 2 days old. The priority of every background task is
continually reassessed. The only foreground task is staying on top of issues
that arise in the groups. Writing a reply like this is a complete waste of my
time, but I don't feel that I was left much choice, since misinformation was
being spread.
> > 8. Do you feel that it is too early, too late, or the right time to address
> > these issues?
>
> A bit late... quite a bit. The right time would have been before they were
> deployed, and before this brouhaha got out of hand.
Actually, many of these issues were indeed addressed beforehand. Anything
that wasn't, wasn't thought of during the original discussions... Some
things were avoided, some things weren't...it's somewhat a matter of
experience and 20-20 hindsight.
--Todd
| | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.admin.general, Todd Lehman writes:
> In lugnet.admin.general, Larry Pieniazek writes:
> > [...]
> > But then LDT gets spent on weird things. Look at how much of it was spent on
> > a password checker that over time due to repeated twiddling became so tuned
>
> You talk as if you seem to know how much actual time was spent on it. Elapsed
> time is a crude indicator of development time.
Time is time, all I have to do is look at the number of posts about it to tell
that some time was spent on it, by you, by me, by others, regardless of how
much time was development time vs playing with it time vs loading up its DB.
I won't presume to estimate exactly how much time was spent but I doubt it was
less than a man day all told.
> > [...]
> > Ratings have been a big administrative waste of time so far. Time that I'd
> > rather see Todd spend on coding useful features or on building or on
> > sleeping, or on having fun with Suz. Or even on doing LDT for geeky, useless
> > but less divisive things like that password checker.
>
> Sorry if you feel the password checker is useless.
Useless was a bit harsh, sorry... let's just call it less useful than quite a
few other things, and more useful than a few other things. And clearly you
enjoyed doing it and enjoyed that other people enjoyed playing with it. Nothing
wrong with geeking out on low priority things, after all. For if that were so,
all of us would be better served doing our real work 100% of the time instead
of enjoying our hobby, eh?
++Lar
| | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.admin.general, Larry Pieniazek writes:
> > Sorry if you feel the password checker is useless.
>
> Useless was a bit harsh, sorry... let's just call it less useful than quite
> a few other things, and more useful than a few other things.
Fair enough.
> And clearly you enjoyed doing it
Not really. Wish I hadn't had to.
> and enjoyed that other people enjoyed playing with it.
Not really, no. It's not intended as a toy or a means of entertainment.
I enjoyed getting feedback on aspects of it to the extent that getting
useful feedback is enjoyable.
> Nothing wrong with geeking out on low priority things, after all.
> For if that were so, all of us would be better served doing our real work
> 100% of the time instead of enjoying our hobby, eh?
Not sure what/if you are insinuating between the lines there, or whether I
should feel insulted by that comment, but having a password validator that
doesn't suck is IMHO a fundamental prerequisite to allowing passwords to be
changed. Anything less is irresponsible. (Yes, I know, allowing too much
time to pass before facilitating the change of passwords is also arguably
irresponsible, but it's a much lesser maximum risk.)
Can we drop this argument?
--Todd
| | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.admin.general, Todd Lehman writes:
> having a password validator that doesn't suck is IMHO a fundamental
> prerequisite to allowing passwords to be changed. Anything less is
> irresponsible.
Even if you have great passwords - can't just anyone in the intervening
networks between the user and LUGNET just snoop in and copy down the
unencrypted password?
Richard
| | | | | | | | | | | | | | | | | | | | | | | | | | | |
Richard Franks <spontificus@__nospam__yahoo.com> wrote:
> Even if you have great passwords - can't just anyone in the intervening
> networks between the user and LUGNET just snoop in and copy down the
> unencrypted password?
Not if it uses https, which I assume it will at some point.
--
Matthew Miller ---> mattdm@mattdm.org
Quotes 'R' Us ---> http://quotes-r-us.org/
Boston University Linux ---> http://linux.bu.edu/
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.admin.general, Richard Franks writes:
> In lugnet.admin.general, Todd Lehman writes:
> > having a password validator that doesn't suck is IMHO a fundamental
> > prerequisite to allowing passwords to be changed. Anything less is
> > irresponsible.
>
> Even if you have great passwords - can't just anyone in the intervening
> networks between the user and LUGNET just snoop in and copy down the
> unencrypted password?
As long as it's using http and not https, yes. Once it's in a cookie, it's
no longer plaintext, so it's less susceptible to snooping although still
susceptible to playback attacks.
--Todd
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.admin.general, Todd Lehman writes:
> In lugnet.admin.general, Richard Franks writes:
> > Even if you have great passwords - can't just anyone in the intervening
> > networks between the user and LUGNET just snoop in and copy down the
> > unencrypted password?
> As long as it's using http and not https, yes. Once it's in a cookie, it's
> no longer plaintext, so it's less susceptible to snooping although still
> susceptible to playback attacks.
Aren't the contents of a cookie simply Base64-encoded? I mean, it's a
wel-known and reversable format.
Cheers,
- jsproat
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Sproaticus <jsproat@io.com> wrote:
> Aren't the contents of a cookie simply Base64-encoded? I mean, it's a
> wel-known and reversable format.
I assume it's a one-way hash of some sort. I'd guess (without looking) that
it's probably md5....
--
Matthew Miller ---> mattdm@mattdm.org
Quotes 'R' Us ---> http://quotes-r-us.org/
Boston University Linux ---> http://linux.bu.edu/
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.admin.general, Jeremy H. Sproat writes:
> In lugnet.admin.general, Todd Lehman writes:
> > In lugnet.admin.general, Richard Franks writes:
> > > Even if you have great passwords - can't just anyone in the intervening
> > > networks between the user and LUGNET just snoop in and copy down the
> > > unencrypted password?
> > As long as it's using http and not https, yes. Once it's in a cookie, it's
> > no longer plaintext, so it's less susceptible to snooping although still
> > susceptible to playback attacks.
>
> Aren't the contents of a cookie simply Base64-encoded? I mean, it's a
> wel-known and reversable format.
No, the last phase of encoding (and thus the first phase of decoding) for
the sign-in cookie is a Base16 (ASCII hex [0-9A-F]) pass. This, however, is
applied to an already-encrypted id/pw combo, which has been passed through a
pad-style encryption which changes each time you ask for a sign-in cookie.
(Thus, you'll never get the same cookie twice even if your password stays the
same.) On the receiving end, after the server decrypts your cookie, it then
reencrypts this data a different way (on the fly) and compares this with the
encrypted version on file in the encrypted-pw table. Thus no raw pw's are
stored anywhere.
--Todd
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.admin.general, Richard Franks writes:
> In lugnet.admin.general, Todd Lehman writes:
>
> > having a password validator that doesn't suck is IMHO a fundamental
> > prerequisite to allowing passwords to be changed. Anything less is
> > irresponsible.
So are you going to enforce that people HAVE to set their passwords to things
that the validator feels don't suck, or are you going to give advice but allow
it anyway?
The former is rather draconian for a site that doesn't handle money. I've asked
this question before but didn't get a clear answer, I don't feel.
++Lar
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.admin.general, Larry Pieniazek writes:
> So are you going to enforce that people HAVE to set their passwords to
> things that the validator feels don't suck,
That is its purpose.
--Todd
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.admin.general, Todd Lehman writes:
> In lugnet.admin.general, Larry Pieniazek writes:
> > So are you going to enforce that people HAVE to set their passwords to
> > things that the validator feels don't suck,
>
> That is its purpose.
But the validator doesn't find non-sucky passwords, it just finds the least
randomised - ie, it will pass something like:
4h(i,>$s& but fail:
4h(i,>$s&-fun
What's the point of allowing people to change from their highly randomised
default LUGNET password (because they have a hard time remembering it), if the
validator only allows something of greater randomisation?
IIRC at least one default LUGNET password failed? My LUGNET password which is
rather easy to remember.. passed with honours!
IMHO it is reasonable to impose a minimum limit of characters, impose an
alpha-numeric mix, maybe even make sure that it isn't just one word known to a
dictionary mixed with one number. But much more than that seems too
restrictive. There is also the counter-security risk - as people have to use
really complicated and random passwords, they tend to start writing them down
in places, password files etc.
Besides which, the longer it takes before users can change their passwords, the
greater chance that other people will stumble upon their LUGNET welcome pack,
which contains their password handily printed out :)
I'm not a security expert - just a user who would rather take the advice of a
password system but have ultimate personal responsibility over my password.
Richard
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Richard Franks <spontificus@__nospam__yahoo.com> wrote:
> But the validator doesn't find non-sucky passwords, it just finds the least
> randomised - ie, it will pass something like:
> 4h(i,>$s& but fail:
> 4h(i,>$s&-fun
It's finding _more_ random passwords in a technical sense of "random". (More
random = containing no sequences. Or more accurately, no part of the number
follows from any other part.)
I agree that the super-cool validator may be overkill for the current state
of LUGnet -- there's no money or credit card information involved. However,
it may be quite reasonable for the future.
--
Matthew Miller ---> mattdm@mattdm.org
Quotes 'R' Us ---> http://quotes-r-us.org/
Boston University Linux ---> http://linux.bu.edu/
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.admin.general, Matthew Miller writes:
> Richard Franks <spontificus@__nospam__yahoo.com> wrote:
> > But the validator doesn't find non-sucky passwords, it just finds the least
> > randomised - ie, it will pass something like:
> > 4h(i,>$s& but fail:
> > 4h(i,>$s&-fun
>
> It's finding _more_ random passwords in a technical sense of "random". (More
> random = containing no sequences. Or more accurately, no part of the number
> follows from any other part.)
Yup - you're right - my squiff (I meant *more*) :)
> I agree that the super-cool validator may be overkill for the current state
> of LUGnet -- there's no money or credit card information involved. However,
> it may be quite reasonable for the future.
I'd be happy with a user-responsible password for membership logins (ie 90% of
membership use including posting privilidges), but with authorisation through a
LUGNET-validated password for more intimate services (ie financial). I think
Todd suggested that 2-tier password scheme already?
Richard
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
(canceled)
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
I can't believe that Larry posted this twice (accident maybe, maybe not). I
am with Larry on this one. This is a problem that requires a simple
solution. Please do not confuse simple with simplistic. It is a
complicated problem; the solution, while perhaps complicated in it's
synthesis, needs to be simple. Listen to Larry, he will guide you toward
the light!
Build On!
John Matthews
(It's not my fault that Larry is usually right)
Larry Pieniazek <lar@voyager.net> wrote in message
news:FtHnrw.IM9@lugnet.com...
> In lugnet.admin.general, Richard Franks writes:
>
> > I'd be happy with a user-responsible password for membership logins (ie • 90% of
> > membership use including posting privilidges), but with authorisation • through
> a
> > LUGNET-validated password for more intimate services (ie financial).
>
> I wouldn't.
>
> Look. I've read through the plan several times. There is nothing there • that
> needs this *insane* level of protection. Nothing. Really.
>
> We are *not* talking missile lanuch codes here, people.
>
> Two levels of passwords is ridiculous. And what is safer, a sort of easy • to
> crack password that is memorised, or a hard to crack password that is kept • in a
> cookie and written on a sticky and kept in the users wallet? The latter.
>
> Use the checker to tell the user that their password isn't very secure and • that
> the system can't be held responsible if someone hacks it and starts • posting
> under their name, submitting ratings, or heaven forbid, puts in some bids • or
> transfers funds out of their account to another user's account.
>
> Then ask them if they're OK with that and OK with the fact that the system
> *isn't* their daddy and isn't going to be able to protect them from every
> conceivable thing that could go wrong. Let's get a grip. We are NOT • talking
> power plant control codes either.
>
> ++Lar
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.admin.general, John Matthews writes:
> I can't believe that Larry posted this twice (accident maybe, maybe not).
It was an accident and I would appreciate the first one being cancelled. There
is a difference in phrasing of less than 1% between the first and second, but
it's crucial.
> I am with Larry on this one. This is a problem that requires a simple
> solution. Please do not confuse simple with simplistic. It is a
> complicated problem; the solution, while perhaps complicated in it's
> synthesis, needs to be simple. Listen to Larry, he will guide you toward
> the light!
I appreciate the support but I don't actually agree with John. At least not
when he says this is a complicated problem.
Let me put my cards on the table here. I would claim I know as much about what
Lugnet is intended to be as anyone else who is peering in from the outside can.
Certainly Todd knows more, but I claim I know as much as anyone possibly can
that doesn't know what Todd knows but hasn't shared with us. (for perfectly
valid reasons, mind you)
Further,
- I have been here from the beginning
- I have read the plan
- I have a fair bit of experience in evaluating requirements from rather
sketchy information, as well as a fair bit of experience in estimating
development effort both before the fact based on those same sketchy
requirements, and after the fact by observing developers who sometimes want to
hide how much effort they put out.
So my professional judgement of what is required, based on the evidence
available to me is that... this is NOT a complex problem. This site (based on
the requirements that are public knowledge) does not need or deserve elaborate
security measures for the casual user. And that's what 99% of us are. Casual
users visiting a hobbyist site.
What is being discussed is more elaborate security than 99+% of commercial
sites have. And I'm arguing from authority. After all, I build these for a
living. Some sites I have been involved in building move millions of dollars a
day.
It's not justifiable from a development effort perspective.
It's not justifiable from a user interface perspective.
Now, as I always say, Todd's gold, Todd makes the rules, Todd can do what he
wants.
But if you want me to shut up about this you either have to flat out say
"shut up" to me *and* everyone else, or you have to convince me differently.
Nothing in the requirements visible to me can justify a need for this elaborate
security. Multiple layers of passwords? I just don't see the benefits being
worth the cost.
Just ignoring me isn't going to get me to shut up, Todd.
Why am I raising such a big stink? Because human factors matter. They matter a
lot, and they are more important than just about anything else. The human
factors here now aren't as good as they could be. Preferences and passwords are
broken. A robust design for them is not hard to come up with (go look at
Yahoo, for example... it is fast and unobtrusive, it reprompts you for the
same password in areas where you wouldn't want a casual visitor to your
machine to have access to) but won't be achieved by fiddling around the edges
one feature at a time, it needs to be realised by a holistic approach that
takes the vision in the plan and turns it into concrete requirements that can
be implemented in a staged way.
Keep fiddling and you'll get a patchwork and you'll do a lot of backing and
filling, way more than you have to. Iterative design and development is the way
to go but there has to be more than a vague vision for the iteration beyond the
next, or patches on top of kludges is what you'll get.
Larry Pieniazek
System Architect, Project Manager, Estimator, General Nuisance and proud of
it...
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.admin.general, Richard Franks writes:
> I'd be happy with a user-responsible password for membership logins (ie 90% of
> membership use including posting privilidges), but with authorisation through • a
> LUGNET-validated password for more intimate services (ie financial).
I wouldn't.
Look. I've read through the plan several times. There is nothing there that
needs this *insane* level of protection. Nothing. Really.
We are *not* talking missile lanuch codes here, people.
Two levels of passwords is ridiculous. And what is safer, a sort of easy to
crack password that is memorised, or a hard to crack password that is kept in a
cookie and written on a sticky and kept in the users wallet? The latter?
Hardly!
Use the checker to tell the user that their password isn't very secure and that
the system can't be held responsible if someone hacks it and starts posting
under their name, submitting ratings, or heaven forbid, puts in some bids or
transfers funds out of their account to another user's account.
Then ask them if they're OK with that and OK with the fact that the system
*isn't* their daddy and isn't going to be able to protect them from every
conceivable thing that could go wrong. Let's get a grip. We are NOT talking
power plant control codes either.
++Lar
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.admin.general, Richard Franks writes:
> I'd be happy with a user-responsible password for membership logins
> (ie 90% of membership use including posting privilidges), but with
> authorisation through a LUGNET-validated password for more intimate
> services (ie financial). I think Todd suggested that 2-tier password
> scheme already?
Ya, sorta... But not so much two different states of logins as two tiers of
passwords which would both be required (only if you wanted it that way) before
you'd be considered actually logged in. In other words, you could give two
passwords (one strong, one weak), leaving one in a cookie permanently and
putting the other in a cookie only temporarily.
When might something like that be useful? Say you'd like to log in from work
during the workday, but you don't want to leave yourself logged in while you're
away from the keyboard (at lunch, in a meeting, in the loo, etc.), but for
practical reasons, you don't want to type a full-strength password every time
you log in.
The two-password combination would allow you to log in "halfway" using a
first password which would go into a first cookie on your machine. You could
leave that there 24 hours a day without worrying about abuse because it would
be useless to anyone without the other half. Then, when you wanted to log in
for real, you could use a second password (this one could be really simple and
weak and easy to remember) and this would go into a second cookie on your
machine. You'd want that second cookie to stay only as long as you were at
your keyboard -- then when you logged out, only the second cookie would be
deleted.
In other words, think of it this way: Instead of having two passwords in
order to log in, you have two _halves_ of a single password -- kind of like
the medallion in the first Indiana Jones film.
BTW, speaking of two- or multi-tier login states... There won't actually
_be_ a change-password facility per se... Instead, there will be an create-
new-password and a delete-old-password facility. It's important that there
be both because passwords are like keys: You can lose a key, but you tend
to have a back-up key just in case. So in that spirit, you'll be able to
give yourself any number of passwords that you want -- and delete old ones
(if you want) after your newer ones have "taken hold" in your mind and you're
absolutely positive that you don't need the old one anymore. A side-benefit
of having multiple passwords is retaining the option to later add login
attributes to the passwords -- i.e., you use password A to do simple things
(maybe from the public library or at work) and you use password B to do
complex things (say, only from home -- if you want that kind of separation).
Another benefit of multiple passwords is this: No matter how hard or how
many times you tell people never ever to give out their password to anyone,
people still sometimes do. If they're going to do it, it's best to give them
the benefit of the doubt and assume they're doing it for at least what they
consider to be a good reason. Thus, if they needed to give out their password
temporarily to, say, a relative helping them do something on their behalf for
whatever reason (I can't think of anything off-hand but I'm sure it'll come
up), they could actually create a new password just for that and then destroy
that password afterwards (say, the next day) -- all without having to
compromise their "real" password. And that's a benefit that happens purely
for free with zero extra coding, once you have the ability to add and subtract
passwords from a list.
--Todd
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.admin.general, Richard Franks writes:
> In lugnet.admin.general, Todd Lehman writes:
> > In lugnet.admin.general, Larry Pieniazek writes:
> > > So are you going to enforce that people HAVE to set their passwords to
> > > things that the validator feels don't suck,
> >
> > That is its purpose.
>
> But the validator doesn't find non-sucky passwords, it just finds the least
> randomised - ie, it will pass something like:
> 4h(i,>$s& but fail:
> 4h(i,>$s&-fun
>
> What's the point of allowing people to change from their highly randomised
> default LUGNET password (because they have a hard time remembering it), if
> the validator only allows something of greater randomisation?
It's perfectly content to "pass" most 6- to 8- character pw's constructed by
the first letter of successive words, especially if the pw includes a digit,
a capital letter, or a special character. Those types of things tend to be
"random" from a brute-force-attack point of view but un-random to the person
generating the pw.
The point is that there are plenty of other pw's that people could come up
with which aren't dangerous, but which are sufficiently random and perfectly
memorable.
> IIRC at least one default LUGNET password failed? [...]
That's entirely possible -- the generator for those doesn't consider
dictionary words, keyboard sequences, etc. But it doesn't necessarily mean
that the pw which failed is risky, so long as they're still chosen from an
equally distributed set of structured input. I can see how it could be
disconcerting, though. :-)
> IMHO it is reasonable to impose a minimum limit of characters, impose an
> alpha-numeric mix, maybe even make sure that it isn't just one word known
> to a dictionary mixed with one number. But much more than that seems too
> restrictive.
:) you and I both know that you're an extremely intelligent adult who has
thought about these things and wouldn't pick something particularly risky --
but the server doesn't know that...(well, I guess it knows that you're an
adult, but...) What of a 10-year-old kid (not that there's anything wrong
with being a 10yo)? Just because someone is a 10yo, should they should be
given a break and allowed to pick a risky pw like "lego4me"?
> There is also the counter-security risk - as people have to use
> really complicated and random passwords, they tend to start writing them
> down in places, password files etc.
Definitely a risk -- but a weak password like "lego4me" or "zaza88" is a
higher worst-case security risk than a strong password which has been written
down.
No matter how strong or weak a password is, if someone writes it down or tells
it to a friend, there's the possibility that someone in that person's nearby
vicinity could use their password -- that's always a risk, and the blame lies
entirely with the user if something goes awry there.
On the flipside, if someone chooses a weak password and never writes it down
and never tells it to anyone, but then someone halfway around the globe who
has never met them suddenly guesses it through trial and error or a brute-
force attack, the blame lies entirely with the system and not with the user.
> Besides which, the longer it takes before users can change their passwords,
> the greater chance that other people will stumble upon their LUGNET welcome
> pack, which contains their password handily printed out :)
True, very true. But if someone leaves that password in a place that it can
be discovered by untrusted eyes and subsequently abused, then that's their
own darn fault.
> I'm not a security expert - just a user who would rather take the advice of
> a password system but have ultimate personal responsibility over my password.
Think of it this way: It's not a PR disaster if someone has their written-
down password stolen and used by a friend or coworker or family member --
that's their own irresponsibility. It -is-, OTOH, a huge PR disaster if
someone chooses a weak password and their account is hacked. There is a
middleground where both extremes are avoided -- where people can pick their
own passwords which don't "have to" be written down and which aren't
particularly dangerous either.
Perhaps the password strength analysis tool should have two thresholds for
the "pass" state:
- Pass if 100% or higher
- Pass with a warning if between 50% and 100%
- Fail if 50% or lower
This would still weed out dictionary words and awful keyboard sequences like
'zaza' and 'qwerty' and 'mnbvcxz' and '3edcvfr4' but allow more (in practice)
than it currently does. I'm not sure if this is what Larry meant or if he
was suggesting an infinitely-low fail threshold.
I don't have a problem with two thresholds as long as the fail-in-practice
threshold isn't too much lower than the fail-in-theory threshold.
--Todd
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.admin.general, Todd Lehman writes:
> The point is that there are plenty of other pw's that people could come up
> with which aren't dangerous, but which are sufficiently random and perfectly
> memorable.
Maybe I'm just miffed because it failed *all* of the passwords I use? :) If I
did anything that even remotely required great security that would be a problem
I guess!
> > IMHO it is reasonable to impose a minimum limit of characters, impose an
> > alpha-numeric mix, maybe even make sure that it isn't just one word known
> > to a dictionary mixed with one number. But much more than that seems too
> > restrictive.
>
> :) you and I both know that you're an extremely intelligent adult who has
> thought about these things and wouldn't pick something particularly risky
*mumble*mumble* Look over there - a MISB Galaxy Explorer!
> What of a 10-year-old kid (not that there's anything wrong
> with being a 10yo)? Just because someone is a 10yo, should they should be
> given a break and allowed to pick a risky pw like "lego4me"?
It's not just children - there are lots of adults out there with even mild
learning difficulties that might find it hard to remember more randomised
passwords.
> On the flipside, if someone chooses a weak password and never writes it down
> and never tells it to anyone, but then someone halfway around the globe who
> has never met them suddenly guesses it through trial and error or a brute-
> force attack, the blame lies entirely with the system and not with the user.
Just out of curiousity - would LUGNET allow brute-force or trial and error
attacks? Something like sending an email warning after 3 fails, then locking
the account for 24 hours after 5 fails would somewhat negate the danger of
those types of attacks?
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.admin.general, Richard Franks writes:
> Maybe I'm just miffed because it failed *all* of the passwords I use?
Me too. I mean, I'm not miffed (I have *much* better things to get miffed
about) but it did fail, without exception, every password I have ever used.
> If I
> did anything that even remotely required great security
I do. And the things I apply them to have checks for weak passwds.
I suspect that they aren't as tight because they use a secondary measure to
prevent brute force (three missed passwd attempts means you have to get your
passwd manually reset).
eric
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.admin.general, Eric Joslin writes:
> (three missed passwd attempts
In a row. Very important phrase I left out.
> means you have to get your
> passwd manually reset).
eric
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.admin.general, Richard Franks writes:
> Maybe I'm just miffed because it failed *all* of the passwords I use? :)
Are there any that it gave between 0% and 100% to? (i.e., not < 0% ?)
> [...]
> Just out of curiousity - would LUGNET allow brute-force or trial and error
> attacks? Something like sending an email warning after 3 fails, then locking
> the account for 24 hours after 5 fails would somewhat negate the danger of
> those types of attacks?
Eeek -- no! -- locking people out on a failed login attempt would certainly
negate the danger of a brute-force of attack, but it would make an entirely
new type of attack (an even worse one!) possible. Consider:
$url = <URL of member sign-in page>
foreach $m (1..1000) # Loop over all members
{
foreach (1..5) # Attack each member 5 times
{
$pw = <generate random nonsense>
<HTTP POST to $url with $m and $pw>
}
}
--Todd
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.admin.general, Todd Lehman writes:
> In lugnet.admin.general, Larry Pieniazek writes:
> > So are you going to enforce that people HAVE to set their passwords to
> > things that the validator feels don't suck,
>
> That is its purpose.
Draconian and rather big-parentish. Why can't I take the risk of a sucky
password if I so choose? Not that I personally would, mind you.
Now, unlike government jackbootedness, we do as consumers have a choice not to
use Lugnet... but what exactly is the harm of allowing sucky passwords? It
falls entirely or for the most part on the person who made the poor choice. Why
be their daddy?
++Lar
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.admin.general, Larry Pieniazek writes:
> Draconian and rather big-parentish. Why can't I take the risk of a sucky
> password if I so choose? Not that I personally would, mind you.
You put more at risk than your own data or matters when you choose a sucky
password. (Think about it.)
> Now, unlike government jackbootedness, we do as consumers have a choice not
> to use Lugnet... but what exactly is the harm of allowing sucky passwords?
Increased probability of successful brute-force compromises.
> It falls entirely or for the most part on the person who made the poor
> choice. Why be their daddy?
Have I somehow given you the impression that that the only purpose of the
validator is to protect data?
--Todd
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Todd Lehman wrote:
> > Now, unlike government jackbootedness, we do as consumers have a choice not
> > to use Lugnet... but what exactly is the harm of allowing sucky passwords?
>
> Increased probability of successful brute-force compromises.
true, but can't you limit the number of attempts to, say, 5 in 30 minutes... that will make brute force attacks impractical...
:)
Dan
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.admin.general, Dan Boger writes:
> Todd Lehman wrote:
> > > Now, unlike government jackbootedness, we do as consumers have a choice
> > > not to use Lugnet... but what exactly is the harm of allowing sucky
> > > passwords?
> >
> > Increased probability of successful brute-force compromises.
>
> true, but can't you limit the number of attempts to, say, 5 in 30 minutes...
> that will make brute force attacks impractical...
How without opening an equally dangerous door?
--Todd
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Todd Lehman wrote:
> > > Increased probability of successful brute-force compromises.
> >
> > true, but can't you limit the number of attempts to, say, 5 in 30 minutes...
> > that will make brute force attacks impractical...
>
> How without opening an equally dangerous door?
Well, for a brute force attack to be successful, they have to try 100,000s of passwords... if you limit them to 5 tried every 30 minutes, it's pretty certain that they won't stumble upon the correct password before the password owner dies...
Or are you referring to a different door?
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.admin.general, Dan Boger writes:
> Or are you referring to a different door?
Denial of service. I could write a bot that wakes up every 4 minutes and
tries 6 random passwords for your account (and theoretically every one else's
too) thus denying you (or theoretically anyone) the ability to get on as a
member, because no matter when you try, you will already be locked out for
that time period.
++Lar
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.admin.general, Todd Lehman writes:
> In lugnet.admin.general, Larry Pieniazek writes:
> Have I somehow given you the impression that that the only purpose of the
> validator is to protect data?
Who said that? Not me...
++Lar
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Larry P and then Todd L wrote:
> > So are you going to enforce that people HAVE to set their passwords to
> > things that the validator feels don't suck,
>
> That is its purpose.
In that case, you may as well not bother allowing us to change passwords
since we can only change to one just as random and hard to remember,
which will also go up on a yellow sticky on the monitor like the current
one is... (if I worked in an office I wouldn't do that, but since I work
from my home no-one else is going to see the array of yellow stickies
except me, and I don't post the $$-related ones).
Seriously, I'm pretty good at remembering weird numbers (I have my
library card PIN, bank card PIN, and several bank account #s memorised)
but I am getting totally over-passworded lately and it's just not
possible to remember them all. What's going to be so earth-shatteringly
important in the member facilities on LUGNET that you have to force a
password which is far tighter than the ones I use to access my bank and
CC accounts over the net?
Kevin
--
Personal Lego Web page:
http://ourworld.compuserve.com/homepages/kwilson_tccs/lego.html
eBay auctions:http://members.ebay.com/aboutme/kevinw1/
Subscribe to my Lego auction mailing list:
http://www.onelist.com/subscribe/Legopartsales?referer=1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Todd Lehman skrev i meddelandet ...
> In lugnet.admin.general, Larry Pieniazek writes:
> > So are you going to enforce that people HAVE to set their passwords to
> > things that the validator feels don't suck,
>
> That is its purpose.
I think that's unwise (to _force_ people to use an acknowledged pw). Two
reasons:
- one cannot choose a password that is easy to remember --> it will be written
down in some easy accessible place.
- by disallowing some passwords, you are limiting the number of possible
passwords, i.e. you are making a brute force attack easier.
- the refutation of a password makes the customer irritated, especially if
there's no _obvious_ (to the customer) reason.
Test for a minimum length, and force a mix of letters (upper and lower case)
and numbers/special characters, and it will be good enough.
[OK, that was three things, but who said I can count?]
--
Anders Isaksson, Sweden
BlockCAD: http://user.tninet.se/~hbh828t/proglego.htm
Gallery: http://user.tninet.se/~hbh828t/gallery.htm
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.admin.general, Anders Isaksson writes:
> Todd Lehman skrev i meddelandet ...
> > In lugnet.admin.general, Larry Pieniazek writes:
> > > So are you going to enforce that people HAVE to set their passwords to
> > > things that the validator feels don't suck,
> >
> > That is its purpose.
>
> I think that's unwise (to _force_ people to use an acknowledged pw). Two
> reasons:
>
> - one cannot choose a password that is easy to remember --> it will be
> written down in some easy accessible place.
Can't or won't?
> - by disallowing some passwords, you are limiting the number of possible
> passwords, i.e. you are making a brute force attack easier.
I don't believe that's the case.
http://www.lugnet.com/admin/general/?n=5788
> - the refutation of a password makes the customer irritated, especially if
> there's no _obvious_ (to the customer) reason.
I may have to make a short FAQ page.
> Test for a minimum length, and force a mix of letters (upper and lower case)
> and numbers/special characters, and it will be good enough.
SW:Ep1
M:Tron6989
70'sLEGO
2*4Brick
Pi3.14159
12:34Sunday
--Todd
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.admin.general, Todd Lehman writes:
> > Test for a minimum length, and force a mix of letters (upper and lower case)
> > and numbers/special characters, and it will be good enough.
>
> SW:Ep1
> M:Tron6989
> 70'sLEGO
> 2*4Brick
> Pi3.14159
> 12:34Sunday
Oops, almost forgot to list the classic counterexample!
E=mc^2
That uses a mix of...
* At least one uppercase letter from A-Z
* At least one lowercase letter from a-z
* At least one numeric digit from 0-9
* At least one "special" character
...and yet it's still a terrible password.
--Todd
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
Todd Lehman skrev i meddelandet ...
> In lugnet.admin.general, Anders Isaksson writes:
> >
> > - one cannot choose a password that is easy to remember --> it will be
> > written down in some easy accessible place.
>
> Can't or won't?
I'm not sure what you're asking here...
What I tried to say was:
If I have to construct a (for me) strange password, 'just to please the
system' (that's how most users see it, at least), the probability of my
remembering it is lower than if the system accepts whatever I choose. The
harder it is to remember, the higher the probability that I have to keep it
written down somewhere (easily accessible).
--
Anders Isaksson, Sweden
BlockCAD: http://user.tninet.se/~hbh828t/proglego.htm
Gallery: http://user.tninet.se/~hbh828t/gallery.htm
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.admin.general, Anders Isaksson writes:
> I'm not sure what you're asking here...
oh, sorry. I was asking if you meant that people (a) actually wouldn't be
_able_ to choose a password that was easy for them to remember or (b) actually
could but wouldn't bother trying to come up with one that was easy for them to
remember. In other words, did you mean that you would be inclined to come up
with something difficult to remember but which passed, and then simply write
that down somewhere, or would you take the time to come up with something that
you could actually remember easily?
> What I tried to say was:
> If I have to construct a (for me) strange password, 'just to please the
> system' (that's how most users see it, at least), the probability of my
> remembering it is lower than if the system accepts whatever I choose. The
> harder it is to remember, the higher the probability that I have to keep it
> written down somewhere (easily accessible).
I take it as a given that most people will still write a password down
somewhere no matter how easy or difficult it is for them to remember (if they
feel that password is important) just in case they might forget it. Even if
most people don't, it certainly doesn't alarm me one bit knowing that some
people would -- and do.
Maybe they write it down backwards, or shifted by one letter, or letter-case
flopped, or even raw, but it's still safer for them and for LUGNET if they
keep a written record of it in a safe place (such as their wallet or purse
or bureau at home) than if they have a weak password which could be guessed
at from any of 100 million nodes on the Internet.
--Todd
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.admin.general, Todd Lehman writes:
> I take it as a given that most people
but not all. I don't.
> will still write a password down
> somewhere no matter how easy or difficult it is for them to remember (if they
> feel that password is important) just in case they might forget it. Even if
> most people don't, it certainly doesn't alarm me one bit knowing that some
> people would -- and do.
>
> Maybe they write it down backwards, or shifted by one letter, or letter-case
> flopped,
I doubt most people that write down passwords apply any of these cyphers to
them but I am just speculating on this particular point.
> or even raw, but it's still safer for them and for LUGNET if they
> keep a written record of it in a safe place (such as their wallet or purse
> or bureau at home) than if they have a weak password which could be guessed
> at from any of 100 million nodes on the Internet.
Fascinating... can you provide a reference for this assertion, or is it just
conjecture? Keeping ATM passwords in one's wallet or purse is a particularly
bad practice, for example. But then, we're talking about something rather
different than money, aren't we?
++Lar
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
From the last two posts, I think I have arrived at my own conclusion on this
matter. Todd wants to protect his hard earned work by issuing complicated
passwords that theoretically cannot be hacked. I can't blame Todd for this
notion, it seems to make a great deal of sense. Larry, on the other hand,
wants to name his password, and he should be allowed to do so. Todd fears
that not all Lugnet users are as sophisticated as Larry, and someone will
name a password that is easily breached. Again, this seems to make a great
deal of sense. While bad for Larry (and many other Lugnet Members), Todd
can protect his network by using these methods. Unfortunately, this leads
me to the conclusion that there is no need for me to become a member! (bad
for Todd). I am not a member, I have no password, and none of this
discussion applies to me. Furthermore, I read Lugnet with a newsreader! As
many people do, I suspect.
What happens next? How does Todd attract me (and other sophisticated users)
to use the web interface and deal with passwords, etc? From where I sit, I
don't think it can be done. Either cut off newsreader access (bad), or
allow folks to name their passwords (bad according to Todd).
This is becoming *way* too complicated. Let me have my newsreader access
without making me feel like I am left out because I choose not to use the
web interface.
Sorry for trouncing your web playground Todd, but that is how I see it.
Build On!
John Matthews
(plans on contributing to the great effort known as LUGnet, just wants
something other than a moving target)
Larry Pieniazek <lar@voyager.net> wrote in message
news:FtHxnL.8r2@lugnet.com...
> In lugnet.admin.general, Todd Lehman writes:
>
> > I take it as a given that most people
>
> but not all. I don't.
>
> > will still write a password down
> > somewhere no matter how easy or difficult it is for them to remember (if • they
> > feel that password is important) just in case they might forget it. Even • if
> > most people don't, it certainly doesn't alarm me one bit knowing that • some
> > people would -- and do.
> >
> > Maybe they write it down backwards, or shifted by one letter, or • letter-case
> > flopped,
>
> I doubt most people that write down passwords apply any of these cyphers • to
> them but I am just speculating on this particular point.
>
> > or even raw, but it's still safer for them and for LUGNET if they
> > keep a written record of it in a safe place (such as their wallet or • purse
> > or bureau at home) than if they have a weak password which could be • guessed
> > at from any of 100 million nodes on the Internet.
>
> Fascinating... can you provide a reference for this assertion, or is it • just
> conjecture? Keeping ATM passwords in one's wallet or purse is a • particularly
> bad practice, for example. But then, we're talking about something rather
> different than money, aren't we?
>
> ++Lar
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
(canceled)
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.admin.general, John Matthews writes:
> [...]
> This is becoming *way* too complicated. Let me have my newsreader access
> without making me feel like I am left out because I choose not to use the
> web interface.
> Sorry for trouncing your web playground Todd, but that is how I see it.
Thanks for your insightful and thoughtful comments, John!
It's really not as complicated as it may seem. There is a simple pw tester,
it does a reasonable job of identifying weaknesses in pw's, and it outputs a
number in a range. It fails anything below a given threshold on its scale.
Every site that allows people to choose their own password has _some_ kind of
validator attached to it. Usually it's something pretty simple like requiring
four or more characters or a mixture of letters, numbers, etc. Some of the
better ones also include dictionary checks.
From my POV, it's not a matter of whether or not to validate pw's with exactly
this sort of thing in combination with dictionary lookups and a couple other
checks, but simply a matter of where to set the threshold for pass vs. fail.
The magic number (whatever it is) has simply to be chosen high enough to be
safe for users and safe for LUGNET, yet low enough to be acceptable from a
human factors perspective. From recent feedback here, it seems that the
threshold may be higher than it should be. (That's OK; it can be adjusted
lower if needed.)
How best to proceed? Let's not talk about whether or not it's a good idea to
use a strict validator. Let's talk about what the validator's threshold could
safely be lowered to.
http://www.lugnet.com/people/members/pwsa/
There are two thresholds in need of being chosen:
1. The threshold above which pw's are considered "strong" (from a statistical
perspective) and passed without protest.
2. The threshold above which pw's are considered "strong enough" (from a
human factors perspective) and passed with protest (i.e., a warning)
and below which pw's are considered "too weak" for comfort and rejected
flat-out.
Maybe #1 ends up staying at 100%, or maybe it lowers to 50%. And maybe #2
needs to be set to 50%, or -25%, or maybe even -300%. The scale can be
adjusted.
If a consensus on what #2 should be cannot be reached, then the last resort
would be to go with a weaker form of strict validation -- something workable
but more importantly something that typical users are used to living with
(like, for example, being at least N characters long and having at least one
uppercase letter and one digit and one non-alphanumeric).
I'd love to hear more opinions from people who consider themselves typical
computer users -- this kind of input (like what John gave) is very helpful.
--Todd
p.s. Multi-Layer passwords (for multi-tiered logins) is just an idea -- not
something on the slate. Don't worry about that being too complicated because,
if it ever would be useful to add, it would only be something purely optional.
It's not part of the present discussion.
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
(canceled)
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
This is an interesting subject. However, I only know one person who keeps a
written note of his password/ATM number etc. The only reason he does this is
because he is dyslexic. Despite that, I'm sure that as more and more web
services now ask for passwords, I suppose people will write down passwords,
use the same one all the time or develop some other strategy.
Scott A
"Larry Pieniazek" <lar@voyager.net> wrote in message
news:FtHxnL.8r2@lugnet.com...
> In lugnet.admin.general, Todd Lehman writes:
>
> > I take it as a given that most people
>
> but not all. I don't.
>
> > will still write a password down
> > somewhere no matter how easy or difficult it is for them to remember (if • they
> > feel that password is important) just in case they might forget it. Even • if
> > most people don't, it certainly doesn't alarm me one bit knowing that • some
> > people would -- and do.
> >
> > Maybe they write it down backwards, or shifted by one letter, or • letter-case
> > flopped,
>
> I doubt most people that write down passwords apply any of these cyphers • to
> them but I am just speculating on this particular point.
>
> > or even raw, but it's still safer for them and for LUGNET if they
> > keep a written record of it in a safe place (such as their wallet or • purse
> > or bureau at home) than if they have a weak password which could be • guessed
> > at from any of 100 million nodes on the Internet.
>
> Fascinating... can you provide a reference for this assertion, or is it • just
> conjecture? Keeping ATM passwords in one's wallet or purse is a • particularly
> bad practice, for example. But then, we're talking about something rather
> different than money, aren't we?
>
> ++Lar
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.admin.general, Todd Lehman writes:
> SW:Ep1
> M:Tron6989
> 70'sLEGO
> 2*4Brick
> Pi3.14159
> 12:34Sunday
NONE of those are bad passwords for the level of security that LUGNET, now, or
ever, (2) will require.
To think differently implies that either there is something far far deeper and
earth shatteringly important about to happen at some point (2), or that there
is a bit of excessive paranoia at work somewhere. People who really don't want
their ID's hacked should use better ones, of course, but J. Random AFOL would
be well served by any of these.
1 - based on what has been revealed publicly
2 - which may be the case, but how would *we* know... Only Todd does.
++Lar
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.admin.general, Larry Pieniazek writes:
> In lugnet.admin.general, Richard Franks writes:
> > In lugnet.admin.general, Todd Lehman writes:
> >
> > > having a password validator that doesn't suck is IMHO a fundamental
> > > prerequisite to allowing passwords to be changed. Anything less is
> > > irresponsible.
>
> So are you going to enforce that people HAVE to set their passwords to things
> that the validator feels don't suck, or are you going to give advice but allow
> it anyway?
>
> The former is rather draconian for a site that doesn't handle money. I've
asked
Not to mention that Lugnet != NSA.
KL
| | | | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.admin.general, Todd Lehman writes:
> Not sure what/if you are insinuating between the lines there, or whether I
> should feel insulted by that comment, but having a password validator that
> doesn't suck is IMHO a fundamental prerequisite to allowing passwords to be
> changed. Anything less is irresponsible. (Yes, I know, allowing too much
I haven't posted with respect to this in a while, but I would like to say that
if you use this current validator to validate what people can choose for
passwords you might as well just not use it and keep sticking people with the
ones you are now.
I've fed it almost every password I've ever used, some of which took more than
a day on a P2 for l0phtcrack to brute-force, and it failed them all.
It's a neat toy - it's fun to throw things that are purely random at it and
have it spit back how worthless as passwords they are. But it's insanely
picky, with the emphasis being on the insanely part.
I've got a password or three now that it passes, taking a tip from your "first
letter of each word of a sentence" comment. But I don't see them as any
better than the multitude it failed.
But I have no desire to argue overmuch about this. You do what you want, but
you need to keep in mind that as LUGNET grows and as you hope to attract more
and more people, ultimately benefiting both the community and you, you could
possibly be sticking those willing to *pay* to be members with a password
system that is about a million times more restrictive than the ones they use
to buy with credit cards and access their bank accounts every day. I wonder
how many people will find the services worth the trouble?
| | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.admin.general, Mike Stanley writes:
> [...]
> I've fed it almost every password I've ever used, some of which took more
> than a day on a P2 for l0phtcrack to brute-force, and it failed them all.
> [...]
> I've got a password or three now that it passes, taking a tip from your
> "first letter of each word of a sentence" comment. But I don't see them
> as any better than the multitude it failed.
> [...]
Thanks for the above data points. How badly did it fail them by?
Did you catch this post from Monday?--
http://www.lugnet.com/admin/general/?n=6459
What threshold number was below the all the number returned for the ones you
tried that it failed? Would a threshold of, say, 50 (instead of the current
100) pass all of the ones that it's currently failing? Would a threshold of
-100?
(The threshold is just a number on a scale -- that scale can be adjusted.)
--Todd
| | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.admin.general, Todd Lehman writes:
> Thanks for the above data points. How badly did it fail them by?
Pretty badly - I know they were all worthless. I didn't really pay attention
to the numbers. I think they were as low negatively, though, as the "first
leter from each word in a sentence" was positively, though.
> Did you catch this post from Monday?--
>
> http://www.lugnet.com/admin/general/?n=6459
Yep.
> What threshold number was below the all the number returned for the ones you
> tried that it failed? Would a threshold of, say, 50 (instead of the current
> 100) pass all of the ones that it's currently failing? Would a threshold of
> -100?
I think they were all < -100. Just tried one of them, and it was -138.
| | | | | | | | | | | | | | | | | | | | | | | | |
I find the labels a bit pejorative, as they impose your thinking on what level
of security is appropriate on what should just be strength metrics.
For example at setting 1 "lax" it fails passwords that I consider perfectly
adequate for the risk level here at Lugnet and which I would use if I could.
The next setting up is "casual" but it is far from casual, it's already shading
up towards quite restrictive.
Suggest you dump the labels and just go with numeric indicators. My lax is
probably -23 on your scale and I would call your lax "serious" and your casual
"moderately insane".
So clearly these labels are going to be divisive if you keep them. Just say you
require security level 2 and leave it at that with no label attached to it.
PS, my opinion remains unchanged, even 2 is way too strong for what is needed
here but that's a different issue.
++Lar
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.admin.general, Larry Pieniazek writes:
> I find the labels a bit pejorative, as they impose your thinking on what
> level of security is appropriate on what should just be strength metrics.
OK, fair enough. Labels gone. Just pure numbers in the drop-down list now.
> For example at setting 1 "lax" it fails passwords that I consider perfectly
> adequate for the risk level here at Lugnet and which I would use if I could.
The label covers (covered) what the setting allows in the worst-case. If you
poke around enough (or, as I've done, run scripts internally that hammer on it
to generate meaningful statistics), you'll find that the "Lax" setting (1)
does indeed pass some very, very bad pw's. It may also fail a few good ones
here and there, but as I'm sure you must realize, false positives are
infinitely more harmless than the reverse.
> The next setting up is "casual" but it is far from casual, it's already
> shading up towards quite restrictive.
It's appropriate to call it casual because it is only a minimal level of pw
security -- it offers approximately 25 bits of protection in the worst case.
(It passes approximately 40% of all 5-character pw's chosen from the alphabet
{a-z,0-9}.) 2^25 is scarcely 30 million combinations to try. That IS casual,
trust me.
> Suggest you dump the labels and just go with numeric indicators. My lax is
> probably -23 on your scale and I would call your lax "serious" and your
> casual "moderately insane".
Here is why "1 - Lax" is in fact lax and not even remotely close to serious:
1. It passes terribly poor 4-character passwords such as "chow", "itso",
and "frob", and in fact passes 90% of all 4-character randomly generated
pw's using a linear distribution of the letters 'a' to 'z'. 26^4 =
456,976 (bad).
2. It passes 95% of all 4-character randomly generated pw's using a linear
distribution of the letters a-z and the digits 0-9. 36^4 = 1,679,616
(also bad).
3. It passes 99% of all 4-character randomly generated pw's using a linear
distribution of the 95 printable ASCII characters. 95^4 = 81,450,625
(still rather bad).
It you believe that any of the above is not lax, then I would posit that you
have at best a weak understanding of even the most basic statistical and
mathematical issues related to pw cracking. (Sorry.)
> So clearly these labels are going to be divisive if you keep them. Just say
> you require security level 2 and leave it at that with no label attached to
> it.
Okie dokie.
> PS, my opinion remains unchanged, even 2 is way too strong for what is
> needed here but that's a different issue.
You go right ahead and believe that. In actuality, it would be totally
irresponsible to lower the bar any further. I've already made it far less
restrictive than it was going to be originally. I really would appreciate
it if you would please stop bugging me about this.
--Todd
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Todd Lehman wrote:
> Here is why "1 - Lax" is in fact lax and not even remotely close to serious:
>
> 1. It passes terribly poor 4-character passwords such as "chow", "itso",
> and "frob", and in fact passes 90% of all 4-character randomly generated
> pw's using a linear distribution of the letters 'a' to 'z'. 26^4 =
> 456,976 (bad).
>
> 2. It passes 95% of all 4-character randomly generated pw's using a linear
> distribution of the letters a-z and the digits 0-9. 36^4 = 1,679,616
> (also bad).
>
> 3. It passes 99% of all 4-character randomly generated pw's using a linear
> distribution of the 95 printable ASCII characters. 95^4 = 81,450,625
> (still rather bad).
>
> It you believe that any of the above is not lax, then I would posit that you
> have at best a weak understanding of even the most basic statistical and
> mathematical issues related to pw cracking. (Sorry.)
Perhaps part of the problem is the relative weights attached to various
elements of strength of passwords. I would generally agree that a 4
character password should not be accepted (of course I suspect most of
us have a significant amount of money protected only by our physical
possesion of a plastic card, and a 4 DIGIT password - I at least chose
an 8 digit PIN the one time I was allowed to chose a PIN, but few ATM
systems these days allow anything other than a 4 digit PIN).
I'm not sure that boiling the strength of a password down to a single
number is the best way to go about it. Why not require a few things,
like minimum length, and let the other checking try and reject trivial
extensions of a short password into the minimum length.
However, you have spoken that this is the final word on Lugnet
passwords, follow-ups to lugnet.off-topic.debate if anyone cares to
continue discussion.
--
Frank Filz
-----------------------------
Work: mailto:ffilz@us.ibm.com (business only please)
Home: mailto:ffilz@mindspring.com
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.admin.general, Frank Filz writes:
> Perhaps part of the problem is the relative weights attached to various
> elements of strength of passwords. I would generally agree that a 4
> character password should not be accepted (of course I suspect most of
> us have a significant amount of money protected only by our physical
> possesion of a plastic card, and a 4 DIGIT password - I at least chose
> an 8 digit PIN the one time I was allowed to chose a PIN, but few ATM
> systems these days allow anything other than a 4 digit PIN).
For the average person or script kiddle to crack a 4-digit PIN via brute
force, they'd have to:
(1) first actually get someone's card; and then
(2) manually try out up to 10,000 combinations, and IIRC, ATM's are programmed
to eat cards after a few failed attempts, and they'll probably be on
videotape too.
For the average person or script kiddle to crack a 4-digit PW on the Internet,
all they need to do is write a tiny script, then sit back and watch it go, all
relatively untraceable if they're being careful. Even if they're not being
careful, it would still be trivial for them to crack a 4-digit PW or cause a
DoS if service were denied after a few failed attempts.
Unless the cracker works in the banking industry, comparing PINs to PW's is
apples and orange, my friend. :)
--Todd
| | | | | | | | | | | | | | | | | | | | | | | |
| |
|
Todd Lehman wrote:
>
> In lugnet.admin.general, Frank Filz writes:
> > Perhaps part of the problem is the relative weights attached to various
> > elements of strength of passwords. I would generally agree that a 4
> > character password should not be accepted (of course I suspect most of
> > us have a significant amount of money protected only by our physical
> > possesion of a plastic card, and a 4 DIGIT password - I at least chose
> > an 8 digit PIN the one time I was allowed to chose a PIN, but few ATM
> > systems these days allow anything other than a 4 digit PIN).
>
> For the average person or script kiddle to crack a 4-digit PIN via brute
> force, they'd have to:
>
> (1) first actually get someone's card; and then
> (2) manually try out up to 10,000 combinations, and IIRC, ATM's are programmed
> to eat cards after a few failed attempts, and they'll probably be on
> videotape too.
(1) is certainly true, (2) is mostly true (there are many ATMs,
including ones in stores which can not eat cards, and probably don't
alert the cashier to take the card [possibly dangerous if the person
using the card is a real criminal]).
> Unless the cracker works in the banking industry, comparing PINs to PW's is
> apples and orange, my friend. :)
True. But my main point was that one shouldn't allow 4 character
passwords in general. The ATM note was just a side note.
Another interesting security flaw I just saw yesterday: I am nearing the
end of my student loan paybacks, and randomly decided to check out if I
could find my account information on the web. I had some paperwork with
the loan servincing agency with me, and noticed an e-mail, so I pulled
up www.host-name.com. Sure enough, they had a screen to get to account
information. What did you need to get there: SSN and ZIP! The screen
allows you to change your address and phone numbers, shows your last 12
payments for each loan, and other status. Not an incredible amount of
information, but somewhat scary.
--
Frank Filz
-----------------------------
Work: mailto:ffilz@us.ibm.com (business only please)
Home: mailto:ffilz@mindspring.com
| | | | | | | | | | | | | | | | | | | | | | |
In lugnet.off-topic.debate, Frank Filz writes:
> True. But my main point was that one shouldn't allow 4 character
> passwords in general. The ATM note was just a side note.
oh! OK. I totally totally totally agree with that!
--Todd
| | | | | | | | | | | | | | | | | | |
In lugnet.admin.general, Todd Lehman writes:
> but I don't feel that I was left much choice, since misinformation was
> being spread.
Oops, wrong word. It wasn't right to say that "misinformation" was being
spread. Rather, speculation was being presented which just happened to be
incorrect. (Big difference!)
--Todd
| | | | | | |
