IWETHEY v. 0.3.0 | TODO
1,095 registered users | 0 active users | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New Another few options:
4) Encrypted passwords. Require an email from the registered address with "Reset Password" or somesuch in the subject string, or some variation thereof.

5) Auto-generate the initial password, with an admonition to change it as soon as possible. Tell the user to KEEP IT AT ALL COSTS. "Reset Password" just sets it to the initial password again without emailing any passwords. If the user loses the initial one completely, they have to resort to getting me to change it.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
Collapse Edited by admin Nov. 30, 2004, 04:50:29 PM EST
Another option:
4) Encrypted passwords. Require an email from the registered address with "Reset Password" or somesuch in the subject string, or some variation thereof.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New I'd rather not vote on solutions until we discuss risks
For example, #4 is a nice idea, but it has nasty corner cases (people do change email addresses, and do you grab the sender domain when they sign up initially?), but all of the solutions have *some* point at which the admin needs to step in and do human authentication.

You've got classic conflicting requirements (and #3 may end up being the best choice--I just hate it to slide by without discussion of the cost vs benefit). This needs a risk discussion, not a "which do you prefer?" discussion.

Quickie risk synopsis:

1. An attacker posts as someone else.
Occurrence: Moderate
Damage: Low (fun 'n games) to Severe (libel, Patriot Act, DCMA, you name it).
Ways to prevent: Strong password security once the account has been created.
Ways to mitigate: Log client IP's with logons?

2. A user forgets their password.
Occurrence: Low
Damage: Low
Ways to prevent: Not many. Training, mostly.
Ways to mitigate: Provide a means to reset the password (without increasing the occurrence of Risk #1).

2.1 Manual Password Reset
2.1.1 Our beloved admin gets deluged with reset requests.
Occurrence: ...? What's a deluge to you?
Damage: ...?
Ways to prevent:
Ways to mitigate:


More after I squash a bug at work...feel free to add in the meantime. But notice that responses to each branch in the risk tree may create more branches. Notice also that anyone can seemingly create any number of logins. Is spam a risk? Is losing a password mitigated by the fact that creating a new account is proabbly easier than bugging the admin?

Etc.
New Re: I'd rather not vote on solutions until we discuss risks
Note that I consider a discussion of risks to be part of "which do you prefer". :-P

Also note that this software, in the future, is not going to be used only for IWETHEY. So what I prefer is not really at issue.

I want to have a discussion about what the best password system is, and why. If it comes down to, "well, this one is best for small sites, and this one for large sites", or "this one is great if you want casual security and minimal intervention, but this one is better if you're running a site where casual security can cost people money/time/legal issues", then I'll probably implement both and create an administrative setting.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New Okay, start with costs of current proposals
What would be the man-hours for our site to maintain option #1, for example? What's the reduction of that number worth to you? Can we take on some of that burden, or otherwise distribute the load? Would donations help? etc.
New Missed the point. :-)
This isn't just going to be used for our site. Costs to me are the last thing on the list as far as I'm concerned.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New Understood, but you're use case #1
I don't have your IWE experience, so your answers would help design the "casual" system. But, it sounds like you're still one design level up from that--still trying to determine market foci. I do think you're going to find different styles for different markets (it's a Prego problem: [link|http://www.gladwell.com/2004/2004_09_06_a_ketchup.html|http://www.gladwell....06_a_ketchup.html]), but short of a major research investment, I'm not sure how far you'll get determining those. The stickier issue is that authentication systems tend to be tightly integrated into applications, so an "administrative setting" will be tough. It might be best to just make your auth system as pluggable as possible and wait for requests from deployers.

Anyway, here's my best guess on where those segments would center and their requirements:

1. Relaxed: Adding an account is very easy, 1 step if possible, but keep the spam low through restrictions (quotas, IP address auditing). Forgotten passwords are emailed in plain text.

2. Strict: Adding accounts is two-factor, multiple steps (I've used folkert's email-a-URL before and it works well). Changing your pw if you already know it is easy. If you don't, resetting it should be subject to the _same_ auth process as creating it (need an email or IP or ..? in addition to name). In other words, if you're going to make resetting tough, make account creation equally tough.

3. Corporate: Restricted set of users; accounts are hard to get and not administered via the web. Make IIS or PAM handle it for the first release, then add your own later on if needed. All auth traffic is out-of-band.

4. Paranoid: Private keys. :)
New I can do private keys...
I keep them on a 32MB Thumb.
--
[link|mailto:greg@gregfolkert.net|greg],
[link|http://www.iwethey.org/ed_curry|REMEMBER ED CURRY!] @ iwethey
No matter how much Microsoft supporters whine about how Linux and other operating systems have just as many bugs as their operating systems do, the bottom line is that the serious, gut-wrenching problems happen on Windows, not on Linux, not on Mac OS. -- [link|http://www.eweek.com/article2/0,1759,1622086,00.asp|source]
Here is an example: [link|http://www.greymagic.com/security/advisories/gm001-ie/|Executing arbitrary commands without Active Scripting or ActiveX when using Windows]
New What do you want the software to do?
Hi,

Some stream-of-consciousness follows:

1) If you want the software to be appropriate for (lack of a better term) "secure" discussions, then - until we have biometric stuff we trust - you probably need to keep track of a bunch of unique information on the user. Rather like an e-commerce site (without the financial information, of course). E-mail addresses, reminder queries and answers, and some other proof of identity perhaps.

You'd have to have checks to keep kiddies at bay (limiting the frequency of password changes, making sure the DB was secure, [link|http://slashdot.org/login.pl?op=mailpasswdform|stuff like /. does] with making user type in the contents of bitmaps, etc.).

If you want to ultimately claim that the password system is fairly secure, you'll have to be prepared to defend it if it breaks and some jerk decides to sue you over it. :-( I wouldn't want that responsibility myself.

2) If you want the software to be low-maintenance, then you probably want to minimize the difficulty in getting the password sent out. But even a simple system would have to have a way to cope with people changing e-mail addresses (unless perhaps it were tied into a new mailing list at iwethey.org? But then you'd simply be shifting remembering ziwethey's password to remembering the e-mail account password.)

Passwords are evil things. I hate them. I have my browser remember passwords for sites I freqent and have others written down on little slips of paper or in my Sony Clie'. I have a recipe I use to construct passwords, but it's not always unique. :-( And I do forget - it's been years since I've logged onto /. so I probably won't be able to resurrect that account. E-mail passwords are worse because they're often buried in the software.

This is a tough problem. And user authentication a problem that I don't think is solvable with passwords. You're either going to have to make users jump through hoops to have a fairly secure, in principle (but have to cope with people not keeping the passwords secure), system; or you're going to make work for yourself; or you're going to have a fairly simple system that might be abusable.

Single-sign-on systems (like MS's Passport) are the way to go in an ideal world. Unfortunately, the world is never going to be ideal.

Hmmm.

Some sort of biometric or common key is needed. Biometrics are too far off. How about the serial number from a FAT-formatted USB solid-state disk drive? 8 characters, easy to find (e.g. chkdsk on Winders), quasi-unique, certainly not guessable in a reasonable amount of time (but not cracker-proof of course). But what do you do when you lose or break the drive? :-/

I vote for whatever would give a reasonable level of security without us having to give up too much information. I also don't want you to have to hand-hold the site too much.

Perhaps something like the following:

1) User requests account, gives e-mail address.
2) iwethey software generates initial password, sends it out to e-mail address.
3) User logs in and is immediately directed to their preferences page. They set a new password, then can enter ziwethey.
4) In Zope (or subsequent) login screen, a reminder is given to remember the password and perhaps encouragement to enable the browser to remember the password.
5) If user subsequently requests to have the password sent, and ResendPassword Timer is large enough, resend the initial password or generate a new one. Set ResendPassword Timer. Goto 3).
6) The VTLUG iwethey mailing list used to send out a reminder e-mail once a year. I think that's a nice touch.

I don't know if you need a challenge question before sending the password. That might be appropriate for a user at a kiosk who can't easily access their e-mail. That might also take care of the problem of e-mail addresses changing (the user would get the password in the browser and then set the e-mail address in the preferences).

In short, don't go overboard on it. Get it ziwethey v2 ported and in a beta state so that we can bang on it! :-) Sites like [link|http://weblog.siliconvalley.com/column/dangillmor/archives/011063.shtml#comments|Dan Gillmor's Blog] need something like z now.

Luck!

Cheers,
Scott.
My $0.04.
New Nope, wrong
I don't know if you need a challenge question before sending the password. That might be appropriate for a user at a kiosk who can't easily access their e-mail.
Even with the challenge question, all that's being proposed is that it will cause the new password to be sent to the user's email address. If you give up the login on the basis of the challenge question, you've just made that the password. And challenge questions are by their nature more easily guessed.
===

Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
New Yes, a *good* challenge question would be needed.
There's probably a database out there of everyone's mother's maiden name. :-(

I still think a kiosk-friendly way of updating a user's login would be useful. Though if we all start dragging around USB Flash drives with [link|http://www.oreillynet.com/pub/wlg/5964|knoppix.sh] then even that might be moot (assuming the kiosk has a USB socket).

Cheers,
Scott.
     zIWT meta: Which is better: - (admin) - (66)
         3) -NT - (mmoffitt)
         1) - (jb4) - (3)
             Not for long, at least... -NT - (admin) - (2)
                 Is that a threat?!? -NT - (jb4) - (1)
                     You should know by now... - (admin)
         3, with verification - (Arkadiy) - (29)
             Seconded. -NT - (Yendor)
             NO - (FuManChu) - (27)
                 Er, buh? - (admin) - (3)
                     That's enough of a detriment not to warrant the risk IMO -NT - (FuManChu) - (2)
                         ? -NT - (admin) - (1)
                             ?? -NT - (drewk)
                 Yeah - (Yendor) - (11)
                     How is that insecure? - (FuManChu) - (2)
                         You're unclear on this. - (admin) - (1)
                             See below. -NT - (FuManChu)
                     You only need one field labeled "Hint" - (tuberculosis) - (7)
                         Sure... - (Yendor) - (6)
                             Bah. - (admin)
                             Not quite - (FuManChu) - (4)
                                 And my point is... - (Yendor) - (3)
                                     I have a standard formula I use for passwords. - (folkert) - (2)
                                         I also have a standard formula - (daemon) - (1)
                                             Ding, Ding, Ding. - (folkert)
                 It's only insecure if the user is allowed to proceed - (imric) - (10)
                     Bah. Risk is the issue. - (FuManChu) - (9)
                         So what's YOUR suggestion? -NT - (admin) - (4)
                             Unfortunately for you #1 ;) - (FuManChu) - (3)
                                 WTF? - (admin) - (2)
                                     Sorry. You're right. I didn't read carefully. - (FuManChu) - (1)
                                         So how does that change your answer? - (admin)
                         Same risk than we have now during login. - (imric) - (2)
                             Same outcome, different risk--the attack surface has doubled -NT - (FuManChu)
                             Not mine. - (CRConrad)
                         Can we please weight the risks - (Arkadiy)
         3) with some safeguards? - (Another Scott)
         4) WikiWay: everything wide open ... muuuaaaahahahahahaha -NT - (drewk) - (1)
             Shaddap wid' yer shaddin' ap... -NT - (admin)
         3 with a "what is your dog's name?" thingie -NT - (Silverlock)
         I'll join Ark, Scott(2), Don(Silverback), and YendorMike: 3+ - (CRConrad) - (2)
             <raises hand> on that last bit. :-) -NT - (Another Scott)
             Aye - 3) with - (imric)
         Another few options: - (admin) - (9)
             I'd rather not vote on solutions until we discuss risks - (FuManChu) - (8)
                 Re: I'd rather not vote on solutions until we discuss risks - (admin) - (7)
                     Okay, start with costs of current proposals - (FuManChu) - (3)
                         Missed the point. :-) - (admin) - (2)
                             Understood, but you're use case #1 - (FuManChu) - (1)
                                 I can do private keys... - (folkert)
                     What do you want the software to do? - (Another Scott) - (2)
                         Nope, wrong - (drewk) - (1)
                             Yes, a *good* challenge question would be needed. - (Another Scott)
         how about 4, the way we do it now - (daemon) - (3)
             Which is? - (Another Scott)
             And what would that be? - (admin) - (1)
                 the way it works now - (daemon)
         How about 5... - (jb4)
         16) Storing them encrypted with a "reset my password" featur - (folkert)
         A variation on 2) - (altmann)
         3), with a question 1st. -NT - (broomberg)
         3 with a proviso - (ChrisR) - (1)
             I like that! -NT - (Arkadiy)
         3. Puts the onus of keeping valid email address on user. -NT - (a6l6e6x)
         3 -NT - (pwhysall)
         6. - (static)
         "zIWT meta: Which is better:" Voting/Ratification (new thread) - (folkert)

Most of what passes for 'humor' in Murica '02.
254 ms