| |
In lugnet.announce, Todd Lehman writes:
>
> I'm happy to announce that formal LUGNET memberships are now available. :)
> So we set it up that you pay what you think is fair, based on what the value
> of LUGNET is to you, with the minimum being 10 dollars (U.S.) for lifetime
> membership, leaving anything else up to you.
If I send an extra $10, can I get a new packet of LUGNET membership stuff, most
importantly my password?
Chris
|
|
| |
In lugnet.people, Christopher L. Weeks writes:
> If I send an extra $10, can I get a new packet of LUGNET membership stuff,
> most importantly my password?
Have you forgotten your password? If so, write me an email from your primary
address and I can now ask the server to generate a new one for you and send
it directly to you via e-mail. You could think of it as a temporary new one
which you could use to sign in and change something you are less likely to
forget or lose, if you prefer.
--Todd
|
|
| |
In lugnet.admin.general, Christopher L. Weeks writes:
> In lugnet.announce, Todd Lehman writes:
> >
> > I'm happy to announce that formal LUGNET memberships are now available. :)
>
> > So we set it up that you pay what you think is fair, based on what the value
> > of LUGNET is to you, with the minimum being 10 dollars (U.S.) for lifetime
> > membership, leaving anything else up to you.
>
> If I send an extra $10, can I get a new packet of LUGNET membership stuff, • most
> importantly my password?
>
> Chris
|
|
| |
In lugnet.admin.general, Christopher L. Weeks writes:
> In lugnet.announce, Todd Lehman writes:
> >
> > I'm happy to announce that formal LUGNET memberships are now available. :)
>
> > So we set it up that you pay what you think is fair, based on what the value
> > of LUGNET is to you, with the minimum being 10 dollars (U.S.) for lifetime
> > membership, leaving anything else up to you.
>
> If I send an extra $10, can I get a new packet of LUGNET membership stuff, • most
> importantly my password?
>
> Chris
Me too. I've now forgotten all 3 of my passwords, including the two new ones
that I worked very hard to come up with memorable phrases that I could
remember and that passed that (*&)&@%&$# insanely strict password check.
Anything I can actually remember, it flags. Even my pet phrases. I gotta start
writing these passwords down.
++Lar
|
|
| |
In lugnet.people, Larry Pieniazek writes:
> In lugnet.admin.general, Christopher L. Weeks writes:
> > In lugnet.announce, Todd Lehman writes:
> > >
> > > I'm happy to announce that formal LUGNET memberships are now available. :)
> >
> > > So we set it up that you pay what you think is fair, based on what the value
> > > of LUGNET is to you, with the minimum being 10 dollars (U.S.) for lifetime
> > > membership, leaving anything else up to you.
> >
> > If I send an extra $10, can I get a new packet of LUGNET membership stuff, • most
> > importantly my password?
> >
> > Chris
>
> Me too. I've now forgotten all 3 of my passwords, including the two new ones
> that I worked very hard to come up with memorable phrases that I could
> remember and that passed that (*&)&@%&$# insanely strict password check.
>
> Anything I can actually remember, it flags. Even my pet phrases. I gotta start
> writing these passwords down.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Ack! Don't you realize that's much more insecure than your semi-secure
easially rememberable passwords? This is retarded. My banks and credit
cards and online trading accounts don't require that much "security", why
does my chat board?
On another topic, I love the new personal inventory. Is there any
way to enter the information in on one page instead of going from set
to set?
KL
|
|
| |
In lugnet.people, Kevin Loch writes:
> On another topic, I love the new personal inventory. Is there any
> way to enter the information in on one page instead of going from set
> to set?
Oops, with duplicate set numbers that might not be a good idea :)
How about adding a UPC field to the db so we can use a CueCat?
KL
|
|
| |
In lugnet.people, Kevin Loch writes:
> Ack! Don't you realize that's much more insecure than your semi-secure
> easially rememberable passwords?
Of course not -- because that's patently false.
Uhhh, if you chronically have trouble remembering good passwords, you should
be writing them down and putting them somewhere *safe* that you trust -- like
your dresser drawer at home, or a jewelry case, or somewhere else safe behind
lock and key that you already trust. Then, if you should happen to forget
your passwords, you can look them up and refresh your memory. There's nothing
inherently insecure about written-down passwords. And something like a PayPal
password (if you can't remember it), write that down encoded somehow, to foil
burglars.
Even if your password is written down and you carry it with you wherever you
go in your wallet, that's *much* better than having a bad password. Think.
The chances of someone stealing a good password from your wallet are *much*
*much* *much* *much* *MUCH* less than the chances of a cracker stealing your
bad and easily breakable password.
> This is retarded.
I'm kinda shocked that you would say something like that, much less actually
believe it. I guess you haven't done the math! (some of which can be found
on the old thread). We're talking 25-bit number space here, Kevin.
> My banks and credit
> cards and online trading accounts don't require that much "security", why
> does my chat board?
False. Bank and credit cards require a lot more security than most people
think. It may seem as though your bank card is protected by a 4- or 8-digit
PIN number, but that's not true! Someone has to steal the card off your
person _and_ know the PIN number in order to steal your money. Oh sure, if
you lost your card and someone found it, they could try brute forcing it at
an ATM -- manually -- at the rate of maybe, at best, 6 or 7 tries per minute,
but unless they're wearing a ski mask, their face is being videotaped. And
even if they get through and steal your money, if you've reported your card
lost or stolen, you probably won't be held liable. And even if you didn't
report it stolen in time, you can probably dispute the charges.
> On another topic, I love the new personal inventory. Is there any
> way to enter the information in on one page instead of going from set
> to set?
Not currently.
--Todd
|
|
| |
Todd Lehman <lehman@javanet.com> wrote in message
news:G1Evq8.A9o@lugnet.com...
> False. Bank and credit cards require a lot more security than most people
> think. It may seem as though your bank card is protected by a 4- or • 8-digit
> PIN number, but that's not true! Someone has to steal the card off your
> person _and_ know the PIN number in order to steal your money. Oh sure, • if
> you lost your card and someone found it, they could try brute forcing it • at
> an ATM -- manually -- at the rate of maybe, at best, 6 or 7 tries per • minute,
> but unless they're wearing a ski mask, their face is being videotaped. • And
> even if they get through and steal your money, if you've reported your • card
> lost or stolen, you probably won't be held liable. And even if you didn't
> report it stolen in time, you can probably dispute the charges.
One point to note, especially for anyone planning on visiting Australia.
ATMs around here will eat cards after about four tries, if you fail on
entering the PIN succession.
Cheers ...
Geoffrey Hyde
|
|
| |
In lugnet.people, Kevin Loch writes:
> In lugnet.people, Kevin Loch writes:
> > On another topic, I love the new personal inventory. Is there any
> > way to enter the information in on one page instead of going from set
> > to set?
>
> Oops, with duplicate set numbers that might not be a good idea :)
Internally, it uses a suffix on the set number to avoid ambiguities arising
from duplicates issues of a number, for example:
http://guide.lugnet.com/set/1974_1
http://guide.lugnet.com/set/1974_2
http://guide.lugnet.com/set/1974_3
http://guide.lugnet.com/set/1974_4
(that's three sets, each numbered 1974, within a larger value pack also
numbered 1974 :-).
You can add the _1 suffix on sets where the number was only used once, and it
will automatically canonicalize the URL to a more human-friendly form whenever
possible. For example, if you click to:
http://guide.lugnet.com/set/7190_1
it rewrites the URL as:
http://guide.lugnet.com/set/7190
since 7190 is unambiguous.
But anyway, duplicate set numbers aren't too much of an issue.
> How about adding a UPC field to the db so we can use a CueCat?
Little bang for the buck, but neat geek factor. :-)
--Todd
|
|
| |
In lugnet.people, Todd Lehman writes:
> In lugnet.people, Kevin Loch writes:
> > Ack! Don't you realize that's much more insecure than your semi-secure
> > easially rememberable passwords?
>
> Of course not -- because that's patently false.
>
> Uhhh, if you chronically have trouble remembering good passwords, you should
> be writing them down and putting them somewhere *safe* that you trust -- like
> your dresser drawer at home, or a jewelry case, or somewhere else safe behind
> lock and key that you already trust. Then, if you should happen to forget
> your passwords, you can look them up and refresh your memory. There's nothing
> inherently insecure about written-down passwords. And something like a PayPal
> password (if you can't remember it), write that down encoded somehow, to foil
> burglars.
Wouldn't it be easier to e-mail the forgotten password to the e-mail address
your members input upon registration? That e-mail could be intercepted but I
don't think a lot of people would go into that kind of trouble to be able to
look at someone's personal collection.
|
|
| |
In lugnet.people, Dan Jezek writes:
> Wouldn't it be easier to e-mail the forgotten password to the e-mail address
> your members input upon registration?
I started doing that about 2 weeks ago. It generates a password, sends an
email with that password, then stores the encrypted password. The membership
packet then contains a backup password.
In the case of older members, or if someone deleted the mail -- basically, if
they just can't find it at all -- then the system can regenerate a new one
and send that.
--Todd
|
|
| |
In lugnet.people, Todd Lehman writes:
> Have you forgotten your password?
Yup.
> If so, write me an email from your primary address and...
Done!
Thank you very much.
Chris
|
|
| |
In lugnet.people, Todd Lehman writes:
>
> > My banks and credit
> > cards and online trading accounts don't require that much "security", why
> > does my chat board?
>
> False. Bank and credit cards require a lot more security than most people
> think. It may seem as though your bank card is protected by a 4- or 8-digit
> PIN number, but that's not true! Someone has to steal the card off your
> person _and_ know the PIN number in order to steal your money. Oh sure, if
Actually, all they need to know is my customer number and a PIN to view my
account records. I would consider my bank account records much more valuable
than my LUGNET profile, no offense :)
If the concern is script kiddies cracking accounts, wouldn't it make more
sense to disable accounts (or better IP's) that are attempting cracking
than force users to choose uncomfortable passwords?
You might want to consider letting your users, many of whom understand
the issues and risks as well as you do, decide for themselves what
strength password to use.
Also, I don't think Larry and I have a problem with the fact that you
reject trivial passwords, but that your standards are a bit too high
for practical use. Remember, any security measure should be designed
to delay subversion, not prevent it outright, which is theoretically
impossible. Have you determined what ammound of difficulty is required
before you could detect the intrusion attempt? Or did you set an artificially
high standard (like months or years) without consideration of the impact
it would have on legitemate use? The president would be alot safer if
he never went out in public, but that would interfere unacceptably with
his normal activities.
KL
|
|
| |
In lugnet.people, Kevin Loch writes:
> Actually, all they need to know is my customer number and a PIN to view my
> account records.
ouch. How easy is it for a thief to get your customer number? How many
digits is your PIN?
> I would consider my bank account records much more valuable
> than my LUGNET profile, no offense :)
natch. :)
> If the concern is script kiddies cracking accounts, wouldn't it make more
> sense to disable accounts (or better IP's) that are attempting cracking
Disable accounts on repeated fails and you make it trivial to DoS someone.
Disable IP addresses and you lock out the innocent on shared proxy servers.
> than force users to choose uncomfortable passwords?
Here are some tips on choosing hard-to-guess passwords that are easy to
remember:
http://www.lugnet.com/people/members/password-suggestions
There were some threads on this on Slashdot a while back, and several people
noted that one of the best ways to remember a password is to use it often
in the beginning so that your fingers actually begin to remember it (through
so-called "muscle memory"). Like riding a bike, you tend not to forget it
after a certain point. Some people suggested keeping it written down on a
paper that you keep with your person until you're comfortable that you
absolutely know it and won't forget it, then you eat that piece of paper. :)
LUGNET's pw changer
http://www.lugnet.com/people/members/pw/
lets you add a new password (keeping the old one just in case) before
retiring the old one. Kinda like having a spare set of keys.
> You might want to consider letting your users, many of whom understand
> the issues and risks as well as you do, decide for themselves what
> strength password to use.
Ahh, that is *sooo* tempting -- and I appreciate the practical advice -- but
how many people wouldn't just be lazy and click that checkbox (or whatever it
was)?
"Yah sure, I understand...urrp. OK, bob123cat it is!...Whee!...urrp."
[...two weeks later...]
"Hey, I didn't write that on my page! Hey, that's not my butt! Hey, I'm
not selling that! Hey, I didn't bid on that! What the fsck is going on?!"
Second, how many people with enough cognitive reasing power and/or training
to grok the combinatorics up, down, and sideways don't have the cognitive
ability to invent an easy-to-remember but hard-to-guess password?
> Also, I don't think Larry and I have a problem with the fact that you
> reject trivial passwords, but that your standards are a bit too high
> for practical use.
I'll agree with that. I think they may still be a bit too high. I still
seriously consider Larry's original suggestion of having two thresholds --
one for "this is really highly suggsted" and a slightly lower one for "this
is the lowest safely allowed." The thresholds can be tuned very finely.
> Remember, any security measure should be designed
> to delay subversion, not prevent it outright, which is theoretically
> impossible. Have you determined what ammound of difficulty is required
> before you could detect the intrusion attempt?
A corrupted cookie file could look like an intrusion attempt, although a
corrupted cookie file isn't so likely to result in rapid variations and
permutations without something like stack frame variable corruption.
> Or did you set an artificially
> high standard (like months or years) without consideration of the impact
> it would have on legitemate use? The president would be alot safer if
> he never went out in public, but that would interfere unacceptably with
> his normal activities.
I'm not sure if I'm remembering the figures exactly, but IIRC it currently
passes 6-character pw's containing an average of approximately 24-26 bits of
unique information. To make pw's more "practical" would mean dropping that
even further (26 is already somewhat risky) down to something like probably
18. Even 2^20 is only one million, and 2^18 is only 1/4 million. If someone
ran one innocuous HTTP request per second, it would take less than a week to
make 2^18 attempts in that more relaxed pw validation scenario.
2^18 is open net hockey for crackers.
--Todd
|
|
| |
Hi there!
Excuse me if i am totally lost here...
Is it not so that a 6 letter password containing letters from A to Z and 0
to 9, can have 36^6 different combinations and contains 48 bits in a unique
order?
A binary value containing 0 or 1 in 8 postitions is 2^8, equals 256
/Joakim
"Todd Lehman" <lehman@javanet.com> wrote in message
news:G1FIsA.Etr@lugnet.com...
> I'm not sure if I'm remembering the figures exactly, but IIRC it currently
> passes 6-character pw's containing an average of approximately 24-26 bits • of
> unique information. To make pw's more "practical" would mean dropping • that
> even further (26 is already somewhat risky) down to something like • probably
> 18. Even 2^20 is only one million, and 2^18 is only 1/4 million. If • someone
> ran one innocuous HTTP request per second, it would take less than a week • to
> make 2^18 attempts in that more relaxed pw validation scenario.
>
> 2^18 is open net hockey for crackers.
>
> --Todd
|
|
| |
In lugnet.people, Joakim Olsson writes:
> Hi there!
> Excuse me if i am totally lost here...
> Is it not so that a 6 letter password containing letters from A to Z and 0
> to 9, can have 36^6 different combinations and contains 48 bits in a unique
> order?
> A binary value containing 0 or 1 in 8 postitions is 2^8, equals 256
36^6 is about equal to 2^31. Maybe it was typical 5-character pw's that
resulted in 24-26 bits of true information...I don't remember for sure, it
was many months ago. OK, yes, <calculator poking> 36^5 is about equal to
2^26. Also, IIRC, I think many 5-character pw's were rejected during the
random statistical tests on grounds of being too short and simple. Most of
the random 6-character pw's went through OK. Anyway, 2^18 is open net hockey
and 2^24 is still not so great.
Thanks.
--Todd
|
|
| |
I've been on a few BBSes, quite a while back now, and believe me, some of
the passwords that I came up with were quite alphanumeric, and rather
random.
A hacker's chance of guessing a random, or even semi-random, password is
therefore theoretically rather small. This would make any kind of
brute-force attack rather obvious looking, and moreover, rather easily
traceable. This therefore is a sufficient deterrent to would-be hackers. I
would rather live with a sufficient deterrent to hackers than an
insufficient nightmare which keeps Todd constantly checking with law
enforcement agencies.
Keep up the good work mate!
Cheers ...
Geoffrey Hyde
Todd Lehman <lehman@javanet.com> wrote in message
news:G1FK70.H7p@lugnet.com...
> In lugnet.people, Joakim Olsson writes:
> > Hi there!
> > Excuse me if i am totally lost here...
> > Is it not so that a 6 letter password containing letters from A to Z and • 0
> > to 9, can have 36^6 different combinations and contains 48 bits in a • unique
> > order?
> > A binary value containing 0 or 1 in 8 postitions is 2^8, equals 256
>
> 36^6 is about equal to 2^31. Maybe it was typical 5-character pw's that
> resulted in 24-26 bits of true information...I don't remember for sure, it
> was many months ago. OK, yes, <calculator poking> 36^5 is about equal to
> 2^26. Also, IIRC, I think many 5-character pw's were rejected during the
> random statistical tests on grounds of being too short and simple. Most • of
> the random 6-character pw's went through OK. Anyway, 2^18 is open net • hockey
> and 2^24 is still not so great.
>
> Thanks.
>
> --Todd
|
|
| |
In lugnet.people, Todd Lehman writes:
>
> Disable accounts on repeated fails and you make it trivial to DoS someone.
> Disable IP addresses and you lock out the innocent on shared proxy servers.
>
>
Not if you only disable loggin in as that user from that ip.
> I'm not sure if I'm remembering the figures exactly, but IIRC it currently
> passes 6-character pw's containing an average of approximately 24-26 bits of
> unique information. To make pw's more "practical" would mean dropping that
> even further (26 is already somewhat risky) down to something like probably
> 18. Even 2^20 is only one million, and 2^18 is only 1/4 million. If someone
> ran one innocuous HTTP request per second, it would take less than a week to
> make 2^18 attempts in that more relaxed pw validation scenario.
>
> 2^18 is open net hockey for crackers.
I think a minimum of 6 characters is a good limit. It's the character
diversity that is causeing problems. Also, you could make failed attempts
take a few extra seconds to further delay brute force attacks. You
cold even make successful logins take a few extra seconds just for good
measure.
BTW, no password is required to post right?
KL
|
|
| |
In lugnet.people, Kevin Loch writes:
> In lugnet.people, Todd Lehman writes:
> > Disable accounts on repeated fails and you make it trivial to DoS someone.
> > Disable IP addresses and you lock out the innocent on shared proxy servers.
>
> Not if you only disable loggin in as that user from that ip.
Is there a way to tell if a given IP address is a shared proxy server or not?
If you disable login access as one user from a given IP address, then you
effectively disable login access as _all_ users from that IP address, because
it would be just as trivial to DoS everyone in succession as it would be to
DoS a single person. In other words, disabling logging in as a user from a
given IP address still locks out the innocent on attacks coming through shared
proxy servers.
> I think a minimum of 6 characters is a good limit. It's the character
> diversity that is causeing problems.
Crack programs use dictionaries.
> Also, you could make failed attempts
> take a few extra seconds to further delay brute force attacks.
I'm kinda wary of that because it is so trivial for a potential attacker to
fork multiple copies of itself and work right arond the delay as if it wasn't
even there. If you delay 3 seconds, then a cracker program just forks extra
copies of itself and works in parallel. So sleep-delays over HTTP don't count
for much. On the other hand, a server could probably get around that by
making a password mutex for each IP address, whereupon failure the process who
owns the mutex would delay some number of seconds before releasing the mutex
to the next process. That way, no HTTP process checking a pw could step
around any other.
> You cold even make successful logins take a few extra seconds just for good
> measure.
Cookie == micro-login. Successful logins have to be as fast as possible.
> BTW, no password is required to post right?
Right.
--Todd
|
|
| |
In lugnet.people, Todd Lehman writes:
> In lugnet.people, Kevin Loch writes:
> > In lugnet.people, Todd Lehman writes:
> > > Disable accounts on repeated fails and you make it trivial to DoS someone.
> > > Disable IP addresses and you lock out the innocent on shared proxy servers.
> >
> > Not if you only disable loggin in as that user from that ip.
>
> Is there a way to tell if a given IP address is a shared proxy server or not?
> If you disable login access as one user from a given IP address, then you
> effectively disable login access as _all_ users from that IP address, because
> it would be just as trivial to DoS everyone in succession as it would be to
> DoS a single person. In other words, disabling logging in as a user from a
> given IP address still locks out the innocent on attacks coming through shared
> proxy servers.
>
>
> > I think a minimum of 6 characters is a good limit. It's the character
> > diversity that is causeing problems.
>
> Crack programs use dictionaries.
Um, yes I know that. It's also possible to generate "human random"
dictionaries that speed up brute force of "strong" passwords where
users are forced within certain limits. BTW, I wonder what the keyspace
is of all (8 chars and less as typical) LUGNET filter approved
passwords is? Remember the more you restrict the keyspace the less
secure it is mathematically.
>
> > Also, you could make failed attempts
> > take a few extra seconds to further delay brute force attacks.
>
> I'm kinda wary of that because it is so trivial for a potential attacker to
> fork multiple copies of itself and work right arond the delay as if it wasn't
> even there. If you delay 3 seconds, then a cracker program just forks extra
> copies of itself and works in parallel. So sleep-delays over HTTP don't count
> for much. On the other hand, a server could probably get around that by
> making a password mutex for each IP address, whereupon failure the process who
> owns the mutex would delay some number of seconds before releasing the mutex
> to the next process. That way, no HTTP process checking a pw could step
> around any other.
>
>
Problem solved (login locking).
> > You cold even make successful logins take a few extra seconds just for good
> > measure.
>
> Cookie == micro-login. Successful logins have to be as fast as possible.
>
>
cookie=no dely, unless you are concerned with people hacking cookie/ip pairs.
but successful user/pw login should be delayed exactly the same as user/pw
failiure. If you really wanted to be slick, drop successful and unsuccessful
logins into the homepage with no indication of login status. Give successful
and unsuccessful logins similar cookies. Of course that would impact
the user experience so you wouldn't do that :)
> > BTW, no password is required to post right?
>
> Right.
|
|
| |
In lugnet.people, Kevin Loch writes:
> Um, yes I know that. It's also possible to generate "human random"
> dictionaries that speed up brute force of "strong" passwords where
> users are forced within certain limits. BTW, I wonder what the keyspace
> is of all (8 chars and less as typical) LUGNET filter approved
> passwords is? Remember the more you restrict the keyspace the less
> secure it is mathematically.
http://news.lugnet.com/admin/general/?n=5788
> > [...] On the other hand, a server could probably get around that by
> > making a password mutex for each IP address, whereupon failure the process
> > who owns the mutex would delay some number of seconds before releasing the
> > mutex to the next process. That way, no HTTP process checking a pw could
> > step around any other.
>
> Problem solved (login locking).
I'm very tempted to head in that direction. Even not relaxing the strictness
of the validator, I think it would be wise.
> cookie=no dely, unless you are concerned with people hacking cookie/ip pairs.
Cooking hacking is the logical place for crackers to focus since it's easy
to make the HTTP logs look less un-normal than ten thousand hits all on the
same URL.
BTW, what is cookie/ip pair?
> but successful user/pw login should be delayed exactly the same as user/pw
> failiure.
Why delay successful logins? I thought the only thing that's important is
that the failures take the same amount of time (or a random amount of time).
If two failures take a different amount of time proportional to something like
the matching portion (some old systems long ago did this) people can exploit
that, but what could be exploited by not delaying on a successful attempt?
You can't not give some sort of positive feedback to the user upon success.
> If you really wanted to be slick, drop successful and unsuccessful
> logins into the homepage with no indication of login status. Give successful
> and unsuccessful logins similar cookies. Of course that would impact
> the user experience so you wouldn't do that :)
That would bad for users, ya.
--Todd
|
|
| |
In lugnet.people, Todd Lehman writes:
>
> Cooking hacking is the logical place for crackers to focus since it's easy
> to make the HTTP logs look less un-normal than ten thousand hits all on the
> same URL.
>
> BTW, what is cookie/ip pair?
The BrickShelf uses the cookie returned *and* the ip address that the cookie
was issued to for reauthenticate login. Nobody has complained about loosing
login yet via multiple proxies (i.e. aol). Also, cookies can be made
*much* more difficult than typical passwords (BrickShelf uses 64 bytes).
>
> > but successful user/pw login should be delayed exactly the same as user/pw
> > failiure.
>
> Why delay successful logins? I thought the only thing that's important is
> that the failures take the same amount of time (or a random amount of time).
> If two failures take a different amount of time proportional to something like
> the matching portion (some old systems long ago did this) people can exploit
> that, but what could be exploited by not delaying on a successful attempt?
> You can't not give some sort of positive feedback to the user upon success.
If successful login takes 10ms, and failiures delay by 2 seconds, I know
if I don't receive a response within 100ms I can try again.
>
> > If you really wanted to be slick, drop successful and unsuccessful
> > logins into the homepage with no indication of login status. Give • successful
> > and unsuccessful logins similar cookies. Of course that would impact
> > the user experience so you wouldn't do that :)
>
> That would bad for users, ya.
>
> --Todd
So is not being able to set a pasword they can remember no?
I think we agree in what makes a password stronger or weaker.
My recommendation is to choose the right balance between convenience
and security. If no one is hacking accounts and many users are complaining
about the password filter, then you might want to adjust the filter settings.
My guess is that many more people will explore and use the more advanced
LUGNET features if you do that. I'd like to see more people rate sets,
list inventories and create web pages on LUGNET. I'm almost certain this
password thing is affecting that. Although I have to admit the set
inventory was so cool I actual dug the LUGNET membership card out of the
closet (no minor task) just so I could log in and try it out.
Hmm, this gives me an idea for the next poll...
KL
|
|
| |
In lugnet.people, Kevin Loch writes:
> I think we agree in what makes a password stronger or weaker.
> My recommendation is to choose the right balance between convenience
> and security.
As is mine. Todd has one opinion of where that is. Some people think it is too
strict. Some are happy. I wonder if any think it is too lenient?
> If no one is hacking accounts and many users are complaining
> about the password filter, then you might want to adjust the filter settings.
> My guess is that many more people will explore and use the more advanced
> LUGNET features if you do that. I'd like to see more people rate sets,
> list inventories and create web pages on LUGNET. I'm almost certain this
> password thing is affecting that.
I know it is affecting me. Todd sent me a new password and I set two more that
hopefully I will have better luck remembering, but I still have 3 that are
cluttering up stuff. How do I remove those if I don't know what they are?
++Lar
|
|
| |
In lugnet.people, Kevin Loch writes:
> > BTW, what is cookie/ip pair?
>
> The BrickShelf uses the cookie returned *and* the ip address that the cookie
> was issued to for reauthenticate login. Nobody has complained about loosing
> login yet via multiple proxies (i.e. aol).
But doesn't that make somebody have to log in again if they use *any* kind of
non-static-IP connection -- i.e., a typical dial-up or DHCP connection -- and
not limited only to shared proxy servers? If they're on a typical ISP dial-up
PPP connection and hang up the phone and dial back in ten minutes later, do
they have to log in again to make more changes?
> Also, cookies can be made
> *much* more difficult than typical passwords (BrickShelf uses 64 bytes).
>
> If successful login takes 10ms, and failiures delay by 2 seconds, I know
> if I don't receive a response within 100ms I can try again.
I don't see how that's an effective deterrant.
If successful login takes 10ms, then a single attacking client process with
one child process that it kills after 10-100 ms could make, say, 10 to 20
attempts per second.
If successful logins are delayed by 2 seconds, why can't your client fork
20 copies of itself and try a whole bunch of pw's in parallel? If the server
isn't mutexing on the IP address, you'll know within a few seconds if any
of those worked, with comparable overall throughput in attemps per second to
the single-process attack.
Now, if a server mutexes on the IP address and delays all client processes
connected to an attacking IP address upon login failure, then delaying upon
successful login is moot, because attacks can't be sped up. So in either
case, why bother delaying upon success? Isn't the important thing is to have
a solid way to limit the overall throughput of failed attempts?
--Todd
|
|
| |
In lugnet.people, Larry Pieniazek writes:
> I know it is affecting me. Todd sent me a new password and I set two more
> that hopefully I will have better luck remembering, but I still have 3 that
> are cluttering up stuff. How do I remove those if I don't know what they
> are?
I didn't plan for that. In the beginning, I honestly didn't think that anyone
would ever forget their password (or at least not have it written down
somewhere that they could find it). I'll have to come up with something.
Since the pw's are encrypted on the server and stored in an untagged list,
I can't tell which are the older ones and which are the newer ones. For
now, if you really want the old ones cleared out, I can wipe the entire list,
but then you'd have to take a new one and change that again -- more hassle
than you probably want.
--Todd
|
|
| |
In lugnet.people, Todd Lehman writes:
> In lugnet.people, Larry Pieniazek writes:
> > I know it is affecting me. Todd sent me a new password and I set two more
> > that hopefully I will have better luck remembering, but I still have 3 that
> > are cluttering up stuff. How do I remove those if I don't know what they
> > are?
>
> I didn't plan for that. In the beginning, I honestly didn't think that anyone
> would ever forget their password (or at least not have it written down
> somewhere that they could find it). I'll have to come up with something.
> Since the pw's are encrypted on the server and stored in an untagged list,
> I can't tell which are the older ones and which are the newer ones. For
> now, if you really want the old ones cleared out, I can wipe the entire list,
> but then you'd have to take a new one and change that again -- more hassle
> than you probably want.
No that would work, I wrote down the password you sent me and the two new ones
I chose and they are pretty memorable, I hope. Implement something that
generates a new password AND wipes out ALL the old ones in one fell swoop.
Then send me the new password, I'll discard the old autogenerated (which would
now not be in there anyway), put in the two new ones I chose as easy to
remember (sorry Todd, one is a personal slur on you but it's easy to remember)
and I will be all set.
This "wipe out all passwords and send a new one" is mighty powerful stuff. Use
with extreme caution. (but you can trust ME of course... so go for it...)
++Lar
> --Todd
|
|
| |
Todd Lehman <lehman@javanet.com> wrote:
> ouch. How easy is it for a thief to get your customer number? How many
> digits is your PIN?
My old bank (US Trust) used my social security number + PIN for phone access
to my account. Eep.
--
Matthew Miller ---> mattdm@mattdm.org
Quotes 'R' Us ---> http://quotes-r-us.org/
Boston University Linux ---> http://linux.bu.edu/
|
|
| |
In lugnet.people, Todd Lehman writes:
>
> Here are some tips on choosing hard-to-guess passwords that are easy to
> remember:
>
> http://www.lugnet.com/people/members/password-suggestions
>
> LUGNET's pw changer
>
> http://www.lugnet.com/people/members/pw/
I'm amazed on how complex and sophisticated the Lugnet password system is.
There are the password suggestions, Password strength analyzer which even
includes an internal dictionary and gives you the CPU time that it took to
analyze the password... I tried P4#$37FG and it barely passed. Ability to
have multiple passwords (which means having a separate database table just for
the passwords), retire old passwords, etc, etc.
The funny thing is that the password doesn't really protect anything other
than the rating system and one's collection ... the last time I checked I
could post under someone else's username :-P
|
|
| |
In lugnet.people, Dan Jezek writes:
> I'm amazed on how complex and sophisticated the Lugnet password system is.
> There are the password suggestions, Password strength analyzer which even
> includes an internal dictionary and gives you the CPU time that it took to
> analyze the password... I tried P4#$37FG and it barely passed. Ability to
> have multiple passwords (which means having a separate database table just
> for the passwords), retire old passwords, etc, etc.
Yup, it's a serious system. Most systems don't take pw issues seriously.
> The funny thing is that the password doesn't really protect anything other
> than the rating system and one's collection ... the last time I checked I
> could post under someone else's username :-P
We'll see how many people find it funny nine months from now.
--Todd
|
|
| |
In lugnet.people, Dan Jezek writes:
> [...]
> analyze the password... I tried P4#$37FG and it barely passed. Ability to
> [...]
That's a problem. It does fail too many good pw's, partially because it
tries to be too clever in transmogrifications and 20 different language
lookups in its dictionary of 3 million words. (It was just as easy to put
in that many as it was to put in English only -- there are gobs of word lists
and dictionaries freely available for that sort of purpose.)
--Todd
|
|
| |
In lugnet.people, Todd Lehman writes:
> In lugnet.people, Dan Jezek writes:
> > [...]
> > analyze the password... I tried P4#$37FG and it barely passed. Ability to
> > [...]
>
> That's a problem. It does fail too many good pw's, partially because it
> tries to be too clever in transmogrifications and 20 different language
> lookups in its dictionary of 3 million words.
^^^^^^^^^^^^^^^^^^
Ouch! I can only imagine the time it took you to key all that data in.
|
|
| |
In lugnet.people, Dan Jezek writes:
> > That's a problem. It does fail too many good pw's, partially because it
> > tries to be too clever in transmogrifications and 20 different language
> > lookups in its dictionary of 3 million words.
> ^^^^^^^^^^^^^^^^^^
> Ouch! I can only imagine the time it took you to key all that data in.
FTP standard ASCII text document, one word per line. Convert to ISO-8859-1
if necessary (character-based search & replace, quick). Feed to indexer via
pipe. Walk away, sip coffee, come back later, it's all done. No typing.
--Todd
|
|
| |
Larry Pieniazek wrote:
> This "wipe out all passwords and send a new one" is mighty powerful stuff. Use
> with extreme caution. (but you can trust ME of course... so go for it...)
A solution to this could be to do the following:
- when someone asks for a password reset, create a new password for
them, put it in the list, also put it in a special "reset account"
password file (along with the ID).
- when the user receives the "reset" password, they log on using it, and
go to the "reset" page (the system could even detect the use of this
password and automagically send you to this page)
- when the user clicks on the "reset password" button (after reading
what will be done), the system removes all passwords from the password
file, then the system takes the the new password (which it conveniently
has in the reset account file), and automatically enters it into the
main password file. Once this is done and comitted to disk, the entry
is removed from the "reset password" file.
- if a system crash interrupts this, the system will also check the
"reset password" file to allow you to log on.
- There should also be an "oops" button which removes the reset password
from both files and effectively cancels the reset.
- If the reset password is not used within a certain time limit, it
should be cleared.
This should block DOS by resetting someone's passwords since the person
who receives the e-mail must take action on it.
--
Frank Filz
-----------------------------
Work: mailto:ffilz@us.ibm.com (business only please)
Home: mailto:ffilz@mindspring.com
|
|
| |
In lugnet.admin.general, Dan Jezek writes:
> In lugnet.people, Todd Lehman writes:
> > In lugnet.people, Dan Jezek writes:
> > > [...]
> > > analyze the password... I tried P4#$37FG and it barely passed. Ability to
> > > [...]
> >
> > That's a problem. It does fail too many good pw's, partially because it
> > tries to be too clever in transmogrifications and 20 different language
> > lookups in its dictionary of 3 million words.
> ^^^^^^^^^^^^^^^^^^
> Ouch! I can only imagine the time it took you to key all that data in.
Imagine it is all you *can* do, as Todd didn't actually do the typing, he said
he got lists of words readily available from the 'net that are made available
(by whom?) to aid in building stronger password checkers. (and also to aid in
building dictionary attack robots??)
++Lar
|
|
| |
"Todd Lehman" <lehman@javanet.com> wrote in message
news:G1HDIu.J6p@lugnet.com...
> In lugnet.people, Dan Jezek writes:
> > The funny thing is that the password doesn't really protect anything • other
> > than the rating system and one's collection ... the last time I checked • I
> > could post under someone else's username :-P
>
> We'll see how many people find it funny nine months from now.
So ... are you going to tell us what is going to happen nine months from now
or just leave us hanging?
IMHO, the password checker and system is way to stringent for the system, as
it currently exists, I've worked in places where I've had to have government
security checks and they weren't this concerned over passwords and security.
But, depending on your plans, it my be appropriate in the future.
Either way, it doesn't really matter to me. I keep my password in my Palm,
so it's always with me, no matter how long or convoluted is has to be.
Mike
--
Mike Faunce
mike at faunce dot com
LUGNET #96
|
|
| |
In lugnet.admin.general, Todd Lehman wrote:
> I didn't plan for that. In the beginning, I honestly didn't think that anyone
> would ever forget their password (or at least not have it written down
> somewhere that they could find it).
Huh? Todd, I hope you meant to write, "I didn't think about dealing with
people forgetting their passwords".
People forget passwords *all* *the* *time*. That's why so many sites have
such ridiculously unsecure password requirements -- so people can remember
how to get in.
And writing passwords down doesn't help -- people either either leave them
out in the open, or they put them in a safe place, and forget what that
safe place is.
Steve
|
|
| |
In lugnet.people, Steve Bliss writes:
> In lugnet.admin.general, Todd Lehman wrote:
> > I didn't plan for that. In the beginning, I honestly didn't think that
> > anyone would ever forget their password (or at least not have it written
> > down somewhere that they could find it).
>
> Huh? Todd, I hope you meant to write, "I didn't think about dealing with
> people forgetting their passwords".
No, I meant exactly that: I didn't think that anyone would ever (a) forget
their password or (b) not be able to just go look it up. When you put it in
a cookie, you don't even have to remember it beyond that, unless you move to
different systems or sign out or your cookie file becomes corrupt. I guess
that was naive of me. We sent it out printed-only in the beginning so that
that we could verify that someone had actually received it (kinda like what
PayPal does, but not quite as stringent) and so that they'd have a written
copy they could keep somewhere safe if they ever needed it, or destroy it if
they knew they wouldn't forget it.
> People forget passwords *all* *the* *time*. That's why so many sites have
> such ridiculously unsecure password requirements -- so people can remember
> how to get in.
Yah, OK. Heh heh. I wonder, though, don't people still forget even their
super-insecure bad passwords? BTW, I've read more than one story of someone
reporting that a stubborn friend of theirs (different people) would use a
site's name as their login password. I guess that's pretty hard to forget,
if you're consistent about it. :-)
> And writing passwords down doesn't help -- people either either leave them
> out in the open, or they put them in a safe place, and forget what that
> safe place is.
Well, now that you mention it, I have gotten a few mails from people who said
they can't remember where they put their membership packet. Someone had moved
to a new house and hadn't unpacked it yet, and another person thought their SO
might've cleaned up and put it somewhere.
--Todd
|
|
| |
Todd Lehman <lehman@javanet.com> wrote:
> > The funny thing is that the password doesn't really protect anything other
> > than the rating system and one's collection ... the last time I checked I
> > could post under someone else's username :-P
> We'll see how many people find it funny nine months from now.
I don't find it funny; I'm just glad it hasn't been a problem.
It'd be nice to hack in some sort of GPG-based authentication system....
--
Matthew Miller ---> mattdm@mattdm.org
Quotes 'R' Us ---> http://quotes-r-us.org/
Boston University Linux ---> http://linux.bu.edu/
|
|
| |
Larry Pieniazek <lpieniazek@mercator.com> wrote:
> he got lists of words readily available from the 'net that are made
> available (by whom?) to aid in building stronger password checkers. (and
> also to aid in building dictionary attack robots??)
University of Oxford. <ftp://ftp.ox.ac.uk/pub/wordlists/>. Wordlists have
non-password related uses too, apparently. :)
--
Matthew Miller ---> mattdm@mattdm.org
Quotes 'R' Us ---> http://quotes-r-us.org/
Boston University Linux ---> http://linux.bu.edu/
|
|
| |
In lugnet.people, Todd Lehman writes:
> In lugnet.people, Dan Jezek writes:
> > I'm amazed on how complex and sophisticated the Lugnet password system is.
> > There are the password suggestions, Password strength analyzer which even
> > includes an internal dictionary and gives you the CPU time that it took to
> > analyze the password... I tried P4#$37FG and it barely passed. Ability to
> > have multiple passwords (which means having a separate database table just
> > for the passwords), retire old passwords, etc, etc.
>
> Yup, it's a serious system. Most systems don't take pw issues seriously.
>
>
> > The funny thing is that the password doesn't really protect anything other
> > than the rating system and one's collection ... the last time I checked I
> > could post under someone else's username :-P
>
> We'll see how many people find it funny nine months from now.
>
> --Todd
Huh?
Ther is only one thing I can think of that has a nine month
completion cycle, and it doesn't have a thing to do with passwords.
Could you elaborate?
KL
|
|
| |
In lugnet.people, Kevin Loch writes:
> > We'll see how many people find it funny nine months from now.
>
> Huh?
>
> Ther is only one thing I can think of that has a nine month
> completion cycle, and it doesn't have a thing to do with passwords.
> Could you elaborate?
LOL, no not that. :)
--Todd
|
|
| |
In lugnet.people, Kevin Loch writes:
> In lugnet.people, Todd Lehman writes:
> > In lugnet.people, Dan Jezek writes:
> > > I'm amazed on how complex and sophisticated the Lugnet password system is.
> > > There are the password suggestions, Password strength analyzer which even
> > > includes an internal dictionary and gives you the CPU time that it took to
> > > analyze the password... I tried P4#$37FG and it barely passed. Ability to
> > > have multiple passwords (which means having a separate database table just
> > > for the passwords), retire old passwords, etc, etc.
> >
> > Yup, it's a serious system. Most systems don't take pw issues seriously.
> >
> >
> > > The funny thing is that the password doesn't really protect anything other
> > > than the rating system and one's collection ... the last time I checked I
> > > could post under someone else's username :-P
> >
> > We'll see how many people find it funny nine months from now.
> >
> > --Todd
>
> Huh?
>
> Ther is only one thing I can think of that has a nine month
> completion cycle, and it doesn't have a thing to do with passwords.
> Could you elaborate?
Maybe Todd will finally unveil his gigantic space minifig colony. He's been
promising it since '98 .... That would be something to see! I'm not laughing
any more :-O
- Dan
|
|
| |
In lugnet.people, Dan Jezek writes:
> Maybe Todd will finally unveil his gigantic space minifig colony. He's
> been promising it since '98 .... That would be something to see! I'm not
> laughing any more :-O
Still on the back burner.
http://news.lugnet.com/people/?n=382
--Todd
|
|
| |
In lugnet.people, Todd Lehman writes:
> Still on the back burner.
> http://news.lugnet.com/people/?n=382
And it's a shame, too, since the test models, or preliminary models, or, uh,
whatever you'd qualify them as that I've seen look ultra-sweet.
But I'm hardly one to talk about low model output. I have at least three
things I want to build in my head. Wait. I mean, I have at least three models
in my head that I want to build, and I've done nothing about it so far.
eric
|
|
| |
In lugnet.admin.general, Matthew Miller writes:
> Larry Pieniazek <lpieniazek@mercator.com> wrote:
> > he got lists of words readily available from the 'net that are made
> > available (by whom?) to aid in building stronger password checkers. (and
> > also to aid in building dictionary attack robots??)
>
> University of Oxford. <ftp://ftp.ox.ac.uk/pub/wordlists/>. Wordlists have
> non-password related uses too, apparently. :)
What? You mean there's more to LUGNET than sparring about passwords and spam?
As to the link, thanks, new I had scene it B4. I never knead dictionaries,
personally, except when siteing to refute... Just ask me, I'll be glad to tell
you wot a grate speller I am.
++Lar
|
|
| |
In lugnet.people, Larry Pieniazek writes:
> In lugnet.admin.general, Matthew Miller writes:
> > Larry Pieniazek <lpieniazek@mercator.com> wrote:
> > > he got lists of words readily available from the 'net that are made
> > > available (by whom?) to aid in building stronger password checkers. (and
> > > also to aid in building dictionary attack robots??)
> >
> > University of Oxford. <ftp://ftp.ox.ac.uk/pub/wordlists/>. Wordlists have
> > non-password related uses too, apparently. :)
>
> What? You mean there's more to LUGNET than sparring about passwords and spam?
>
> As to the link, thanks, new I had scene it B4. I never knead dictionaries,
> personally, except when siteing to refute... Just ask me, I'll be glad to tell
> you wot a grate speller I am.
>
> ++Lar
I just figured out how to easially pass the LUGNET pw test. Use
lots of special characters. This one: ^n).F6'%#*><}{#: scores
a whopping 900% with no warnings. Just make sure you throw in a number
a lower case letter and an upper case letter and you are all set.
That bypasses the pesky /<-R4d dictionary translator (numbers <-> words)
that has probably been messing most people up. Of course this does
restrict the keyspace significantly, but at least you won't have to
try 300 passwords to get one that passes.
Of course yours doesn't have to be as long as the 900% example.
It diddn't take too long ot come up with ]4b[G which is only 5 characters
yet passes with 350% and absolutely no warnings. Hey, that's a great
strong pasword. "Excellent" according to the appraisal.
Also, it's easier to pass if you avoid mathematical symbols <>-+#%,
heavilly favoring others []':; and so on.
Basically, avoid regular letters and numbers at all cost.
KL
|
|
| |
In lugnet.people, Kevin Loch writes:
> [...]
> Basically, avoid regular letters and numbers at all cost.
Gee, that was so funny I almost forgot to laugh. There are plenty of
6-character pw's that you can use that have 5 letters and one number or
special character, and plenty of 7-character pw's that you can use that are
all lowercase letters. I don't see why some people are having trouble coming
up with something.
But be that as it may, I would much rather discuss practical ways to limit
brute-force cracking throughput so that the strictness of the validator can
be lowered to something more human-factors-friendly.
--Todd
|
|
| |
In lugnet.people, Mike Faunce writes:
> > We'll see how many people find it funny nine months from now.
> So ... are you going to tell us what is going to happen nine months from
> now or just leave us hanging?
A combination of things... first, by then there will be more things in
place that will matter more; second, the pw validator will very likely be
less stringent; third, I predict that within the next nine months, a major
online banking site such as PayPal will have a major fiasco in the news with
tens or hundreds of thousands of user accounts having been either cracked
via a distributed stealth parallel cracking system or DoS'd through a
distributed and carefully orchestrated DoS attack based on the principle that
they lock someone of their account out if a small number of multiple login
attempts fail rather than having more stringent pw requirements and allowing
a larger number of fails.
--Todd
|
|
| |
In lugnet.people, Todd Lehman writes:
> In lugnet.people, Mike Faunce writes:
> > > We'll see how many people find it funny nine months from now.
> > So ... are you going to tell us what is going to happen nine months from
> > now or just leave us hanging?
>
> A combination of things... first, by then there will be more things in
> place that will matter more; second, the pw validator will very likely be
> less stringent; third, I predict that within the next nine months, a major
> online banking site such as PayPal will have a major fiasco in the news with
> tens or hundreds of thousands of user accounts having been either cracked
> via a distributed stealth parallel cracking system or DoS'd through a
> distributed and carefully orchestrated DoS attack based on the principle that
> they lock someone of their account out if a small number of multiple login
> attempts fail rather than having more stringent pw requirements and allowing
> a larger number of fails.
>
> --Todd
Actually I found PayPal's pw filter to be fairly stringent.
KL
|
|
| |
In lugnet.people, Kevin Loch writes:
> [...] Also, cookies can be made *much* more difficult than typical
> passwords (BrickShelf uses 64 bytes).
I agree! In a cookie, you can put complete random garbage that only the
authentication server knows how to interpret. And if certain bits contain
an index, you can even use a one-time pad or other complex mapping to encrypt
the data so that the pw isn't sent back and forth as plaintext.
--Todd
|
|
| |
Todd - an interesting but minor question to these thread links - if I wanted
the thread unraveled all the way back to it's source post, how would I do
that?
Cheers ...
Geoffrey Hyde
Todd Lehman <lehman@javanet.com> wrote in message
news:G1KG4B.MCt@lugnet.com...
> In lugnet.people, Kevin Loch writes:
> > Actually I found PayPal's pw filter to be fairly stringent.
>
> What do you think about this?--
> http://news.lugnet.com/off-topic/geek/?n=2101
> http://news.lugnet.com/off-topic/geek/?n=2107
>
> --Todd
|
|
| |
In lugnet.people, Geoffrey Hyde writes:
> > What do you think about this?--
> > http://news.lugnet.com/off-topic/geek/?n=2101
> > http://news.lugnet.com/off-topic/geek/?n=2107
>
> Todd - an interesting but minor question to these thread links - if I wanted
> the thread unraveled all the way back to it's source post, how would I do
> that?
When you're viewing an article at the website (such as through one of the
links as shown above), scroll down to the bottom of the page and click one
of the "Entire Thread on One Page" links. You can see the thread in nested
thread form or in chronological form, and at various sizes (whole articles,
snippets, single lines, or just little dots).
--Todd
|
|
| |
In lugnet.admin.general, Kevin Loch writes:
> I just figured out how to easially
Easially?
> pass the LUGNET pw test. Use
> lots of special characters. This one: ^n).F6'%#*><}{#: scores
> a whopping 900% with no warnings. Just make sure you throw in a number
> a lower case letter and an upper case letter and you are all set.
> That bypasses the pesky /<-R4d dictionary translator (numbers <-> words)
> that has probably been messing most people up. Of course this does
> restrict the keyspace significantly, but at least you won't have to
> try 300 passwords to get one that passes.
>
> Of course yours doesn't have to be as long as the 900% example.
> It diddn't take too long ot come up with ]4b[G which is only 5 characters
> yet passes with 350% and absolutely no warnings. Hey, that's a great
> strong pasword. "Excellent" according to the appraisal.
Hey, we better enhance the tester to prevent that password, it's kind of sort
of easy to remember.
<GD&R>
Seriously, I like the active anti cracker defense idea a lot better and I
think that's the better way to solve the problem. Instead of butting heads
with Todd on how secure the password space needs to be due to attack speed,
make it harder to attack.
Everyone wins. Todd gets to be right, we get the password checker turned down
to something reasonable (or off) and crackers get to try a site that's more
likely to be lucrative anyway instead of wasting time here. Like my CU. You
don't even want to know what their password (??) scheme is. It's actually
(even for me, a lax password kind of guy) scary.
++Lar
|
|
| |
In lugnet.people, Todd Lehman writes:
> In lugnet.people, Mike Faunce writes:
> > > We'll see how many people find it funny nine months from now.
> > So ... are you going to tell us what is going to happen nine months from
> > now or just leave us hanging?
>
> A combination of things... first, by then there will be more things in
> place that will matter more; second, the pw validator will very likely be
> less stringent; third, I predict that within the next nine months, a major
> online banking site such as PayPal will have a major fiasco in the news with
> tens or hundreds of thousands of user accounts having been either cracked
> via a distributed stealth parallel cracking system or DoS'd through a
> distributed and carefully orchestrated DoS attack based on the principle that
> they lock someone of their account out if a small number of multiple login
> attempts fail rather than having more stringent pw requirements and allowing
> a larger number of fails.
I was thinking more from the perspective of what you are going to create that
will have a span of 9 months and not what might happen on the internet outside
of LUGNET in 9 months.
This still doesn't explain why you have a sophisticated password system
(including a dictionary of 3 million words in 20 languages which I assume is
for the password check alone?) that doesn't really protect any vital
information while at the same time you have a security hole on the other end
where people can post under other's names.
|
|
| |
In lugnet.people, Dan Jezek writes:
> I was thinking more from the perspective of what you are going to create
> that will have a span of 9 months and not what might happen on the internet
> outside of LUGNET in 9 months.
Well, enough new things that I think it will be hard for anyone to continue
belittling the checking anymore. Plus, as I said before, it's possible (and
likely, I hope) that the checking will be less stringent. Right now I'm
guesstimating that it could safely be made 3 orders of magnitude (base 10,
that is) less stringent, with a bit of clever intrusion detection, tracking,
and deterrants.
> This still doesn't explain why you have a sophisticated password system
It's a foundation?
> (including a dictionary of 3 million words in 20 languages which I assume is
> for the password check alone?)
Well, a password checker worth anything consults a dictionary (among other
checks). Putting in 3 million words in 20 languages is just as easy as
10,000 words from a single language. The dictionary check was actually one
of the easier parts of the checker to implement.
> that doesn't really protect any vital information
> while at the same time you have a security hole on the other end
> where people can post under other's names.
Well, as you are aware, to get authentication in pure NNTP means password-
protecting incoming connections. On the server side, it means throwing a
switch and maintaining a table of usernames and crypted pw's. On the client
side, it means having a much less open news system, and I'm not even sure if
all the popular NNTP clients support pw's, either. I can't look into a
magical crystal ball and know that the NNTP connections will -never- need to
be pw-protected (let's pray they don't) but I do know that it would have been
a fatal mistake to pw protect them at the beginning, and probably at just
about any point as well in the future without an extremely compelling reason.
Even so, just because one portion of a system using a legacy protocol for
message transport happens not to have user authentication, it doesn't follow
that other new portions of the same system should be implemented without it
as well, or implemented poorly.
--Todd
|
|
| |
Todd Lehman <lehman@javanet.com> wrote in message
news:G1EAr4.F49@lugnet.com...
> In lugnet.people, Christopher L. Weeks writes:
> > If I send an extra $10, can I get a new packet of LUGNET membership • stuff,
> > most importantly my password?
>
> Have you forgotten your password? If so, write me an email from your • primary
> address and I can now ask the server to generate a new one for you and • send
> it directly to you via e-mail. You could think of it as a temporary new • one
> which you could use to sign in and change something you are less likely to
> forget or lose, if you prefer.
Oh, hi Todd. I should have checked this NG before emailing you...
Anyway, I emailed you about <thinking> 5 (?) days ago regarding my password,
but I'm now not sure what you mean by primary email... The email address I
initially used when joining lugnet? Because that one is obsolete - I have
yet to change it on my information-thingy-page. Confusion, oh the confusion.
Cordially,
DBR
--
"To infinity and beyond!"
|
|
| |
In lugnet.people, Dylan Bradley writes:
> Oh, hi Todd. I should have checked this NG before emailing you...
> Anyway, I emailed you about <thinking> 5 (?) days ago regarding my password,
> but I'm now not sure what you mean by primary email... The email address I
> initially used when joining lugnet? Because that one is obsolete - I have
> yet to change it on my information-thingy-page. Confusion, oh the confusion.
Hmm, wait, now I'm confused. I don't see you listed. What is your member ID
number? Anyway, by primary email I meant the first one of the (up to) three
that you gave when you signed up to be a member. But I think maybe you're
confusing membership with news posting?
--Todd
|
|
|
