I think it is an issue.
If someone leaves their username and password on a post-it under their
mousepad and the cleaning lady comes in and finds it and she logs in to
eTrade and goes hog wild, she becomes a "bad user". However, customer
support needs to have a sit-down with the "good user", describing proper
password storage locations.
Or if that "good user" is in the middle of a 10 million share trade, he'd be
pissed if he got bumped because the cleaning lady got on his account. You
can't dump them all, or maybe you can. It depends on your business model. Is
it okay to piss people off? Can you still be a successful site if you do?
NAT
-----Original Message-----
From: Jason Lotz [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 05, 2000 10:52 AM
To: '[EMAIL PROTECTED]'
Subject: RE: <CF_porn>...
Jason,
I agree but consider this. If someone gives away there valid login
information, aren't they also a "bad user?" In other words, if I bought an
account and gave the password to some friends I would not be suprised to be
denied service at some point. I would assume that someone else was logged
into my account and I would be right. Therefore, I don't think the "good"
user v. "bad" user problem is actually an issue. Any thoughts?
Jason
-----Original Message-----
From: Jason Egan [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 05, 2000 7:45 AM
To: [EMAIL PROTECTED]
Subject: RE: <CF_porn>...
I've written some only one login at a time scripts, but how would you
determine who was the 'bad' person logging in? By IP address? (or class
c)... Currently when someone logs in a flag is checked, and the time of
login. then with each action the time is updated. No one else can log in
because the flag is set. If the person logged in - logs out, then the flag
is reset and the account can be used again. If they forget to log out,
there was a problem, but then we rely on the time. If the time the account
is trying to be accessed is 5 or more minutes later than the last action
performed by the previous person logged in, then they are permitted to log
in. The session variables also expire after 5 minutes of inactivity, so
there is only one person logged in at a time.
But again I ask, how do you determine the 'bad' user? I thought about IP
restrictions, but it was for a job fair, so the user may be out n' about.
I do like Steve's idea however to change the pw and email the 'good' user
the new pw.
je
-----Original Message-----
From: Steve Nelson [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 05, 2000 8:09 AM
To: [EMAIL PROTECTED]
Subject: Re: <CF_porn>...
I guess the question with this is.... which one do you allow or
disallow? What if the bad person logged in first and the good person
logged in within a couple minutes.... do you kick out the good person?
My thinking is that the account should get locked out somehow.
Maybe after the account has been compromised, it would kick all users
that are using that account out, then email the good person with a new
password. That would require the bad person to have to also break into
the user's email account. This would probably work great as long as the
person's email account is not also compromised
Steve Nelson
Cameron Childress wrote:
>
> I would be interested in hearing about any solution you end up with. For
> the record, I don't run any porn sites...
>
> An idea: I would think that disallowing two logins with the same UN/PW
> would solve this problem.
>
> -Cameron
>
> -----Original Message-----
> From: Steve Nelson [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, July 05, 2000 9:36 AM
> To: Fusebox
> Subject: <CF_porn>...
>
> I have a slightly unusual question to ask.... Does anyone on this list
> manage a pornography site? (you can contact me off the list if you're
> weird about it)
>
> I'm asking, because I was just chatting with a CF developer who runs a
> porn site and he was talking about how everyone once in a while someone
> will buy an account and post the username and password on some 'free
> password list' website and then his site crashes because it can't handle
> the amount of requests.
>
> Anyway, if anyone has dealt with this issue, I'd love to chat about how
> they got around it for a security module I'm working on, or brainstorm
> on potential solutions.
>
> Steve Nelson
> --------------------------------------------------------------------------
--
> --
> To Unsubscribe visit
> http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
> send a message to [EMAIL PROTECTED] with 'unsubscribe' in
> the body.
>
> --------------------------------------------------------------------------
----
> To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
----------------------------------------------------------------------------
--
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
----------------------------------------------------------------------------
--
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
----------------------------------------------------------------------------
--
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or
send a message to [EMAIL PROTECTED] with 'unsubscribe' in
the body.
------------------------------------------------------------------------------
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/fusebox or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
