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,657 by Another Scott 11/30/04 9:10:22 PM Reply	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 by drewk 11/30/04 9:35:34 PM Reply	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 by Another Scott 11/30/04 11:26:03 PM Reply	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.

Welcome to IWETHEY!