Post #185,604
11/30/04 4:32:04 PM
11/30/04 4:50:29 PM
|

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..."

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..."
|
Post #185,623
11/30/04 5:43:54 PM
|

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.
|
Post #185,627
11/30/04 5:53:17 PM
|

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..."
|
Post #185,642
11/30/04 7:39:31 PM
|

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.
|
Post #185,654
11/30/04 8:53:54 PM
|

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..."
|
Post #185,666
11/30/04 10:29:59 PM
|

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. :)
|
Post #185,667
11/30/04 10:40:15 PM
|

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!] @ iwetheyNo 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]
|
Post #185,657
11/30/04 9:10:22 PM
|

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.
|
Post #185,662
11/30/04 9:35:34 PM
|

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]
|
Post #185,670
11/30/04 11:26:03 PM
|

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.
|