On Oct 3, 2006, at 4:01 PM, Dondi M. Stroma wrote:
One time, two different users reported this problem at roughly the
same time. But what is interesting is that not only did they both
enter *a* wrong account, they both entered the *same* wrong account!
are you sure the login routine is working?
the db select could have an issue with it
the password matching could have an issue with it
did you look into how that could have legitimately happened? maybe
these people are making typos and entering the wrong accounts, but in
a right way. i' hear tons of issues stemming from eager auto-
complete fields in safari and firefox.
as i mentioned before on this list, an agency i once worked at made
the brilliant move of taking a contract to handle a 1.800 line for
salon beauty products in addition to the online account management
help line we had to support.
the one lesson i learned from occasionally getting a 'general 1800'
question sent to me, is that people are stupid. really stupid.
really, really , really really really stupid.
on an average day, I would get 10 each of these 2 question/answers
1- Q. I lost my password. I think my account is hairdresser1. My
email is [EMAIL PROTECTED] i always use the password
######. its not working.
Solution: I altered the db to also contain a md5(username) and md5
(email) field. guess how many of them matched?
literally, 50% of the problems were because the person used their
email or username as their password. and then forgot. the other
50%....
2- Q. I logged in, and I'm in someone elses account. This is
broken. My privacy is broken.
Solution: Looking at the new db fields above, what do we see?
the bulk of people, for a hairstyling site, had usernames relating
to hair, with hair in them.
Lets say the person who called was Jane Doe from New York
The database would have:
username password
=========|=========
hairjane | jane
janecuts | jane
janecuts | scissors
janestyle | scissors
nycjane | shampoo
which user is she? which password? why is everything so
similar?
i think about 80% of the passwords that weren't tied to the name /
address of the user came from a pool of 20 salon related words.
Now lets say that Jane Smith is registered. And she's also from
new york.
guess what.. jane smith AND jane doe - more often than you would
expect - would think that they were each other. they'd forget their
name, remember it must have been hair-something/name-something, and
come up with a name that is registered to someone else. then they'd
take a stab at the password, and usually get it right by the 4th or
5th time.
so i don't know... if your logins are caused by user email- or
something that is hard to 'accidentally' come by- then you may very
well be having a technical problem.
but if your system is using a username, its a very real possibility
that your client base isn't that 'security minded', and making
random lucky guesses at passwords and user names that actually do work.
( for what its worth.... we tried using 'strong' passwords, assigned
passwords, and varying schemes to ensure that people couldn't log in
as each other. whenever we did, people stopped using the system.
they hated dealing with passwords they couldn't remember, couldn't
remember where they put the passwords they wrote down, and were too
annoyed with the reset feature. so we rolled back to insecure
passwords ( but migrated out any sensitve info ), and usage went
right back up. people who came across one of these "security bugs"
would actually be nice... and when we feigned 'oh no not another bug'
they would be very apologetic )
And we have almost 100,000 users in our database! The script
keeps a log of the numerical user ID, IP address, and timestamp of
each successful user to login, and whenever someone reports
entering the wrong account, nothing unusual or having a pattern
ever shows up there either. If something was wrong with the login
logic, I would expect to see an entry with the user ID of one user
and the IP of the other user. That's never happened.
i'd suggest logging the form paramters-- get a record of username +
md5(password)
i think you need to track down where/how this problem is manifesting
itself. lets say it is because of some weird caching issue done by
an ISP-- you're not going to be able to fix that.
but on your end, you might be able to do some things to code around it.
i'd keep a log of account attempts for the next few weeks. log what
you've been logging already... but also log in the cookie values, the
form values, and the return values.
find out if these people are getting into the system because they're
sending a cookie/login string with the right details for the wrong
account , if something- somewhere- in your code is ignoring what they
send and using old values, or if something in your code is rewriting
their info with other values.
personally, i'd log
1. incoming form values ( cookie /login page )
2. form values on your server that you submit for verification
3. the verification results
4. the values ( cookie / whatever ) you send back
i'd also log an md5 of every successful username and password combo ,
and go though that looking for errors-- and similarites. you might
just have some popular usernames / passwords.
also, 'normal' isps like comcast etc do a lot of caching and
proxying. especially for dialup users. never eliminate them as
being a source of your problems. especially if their name rhymes
with verizon.
// Jonathan Vanasco
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - -
| FindMeOn.com - The cure for Multiple Web Personality Disorder
| Web Identity Management and 3D Social Networking
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - -
| RoadSound.com - Tools For Bands, Stuff For Fans
| Collaborative Online Management And Syndication Tools
| - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - - -
