Missed the point. :-)

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,654 by admin 11/30/04 8:53:54 PM Reply	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 by FuManChu 11/30/04 10:29:59 PM Reply	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 by folkert 11/30/04 10:40:15 PM Reply	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!] @ *i_wethey* 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]

Welcome to IWETHEY!