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 zIWT meta: Which is better:
1) Storing passwords encrypted, with an administrator necessary to reset them. Secure, annoys the admin.

2) Storing them plaintext with an "email me my password" feature. Not so secure (you have to trust me) but resets don't annoy the admin.

3) Storing them encrypted with a "reset my password" feature that emails a new random password. Possibly the best of both worlds, but easily abused (you could continually reset someone else's password to annoy them). Limit requests. Possibly don't make the new password active until it's used, with a timeout.

4) Encrypted passwords. Require an email from the registered address with "Reset Password" or somesuch in the subject string, or some variation thereof. Limit requests.

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

6) Storing them encrypted with a "reset my password" feature that emails a new random password reset URL. That URL times-out after 24-36 hours or gets removed if another request is made during the timeout period. If the URL never gets used, the reset never happens, but if it does get used, the password is reset by the requestor on that page. Also, limit the number of requests per day, to evade a Mail DoS.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
Expand Edited by admin Nov. 30, 2004, 02:41:04 PM EST
Expand Edited by admin Nov. 30, 2004, 02:47:06 PM EST
Collapse Edited by admin Nov. 30, 2004, 09:02:55 PM EST
zIWT meta: Which is better:
1) Storing passwords encrypted, with an administrator necessary to reset them. Secure, annoys the admin.

2) Storing them plaintext with an "email me my password" feature. Not so secure (you have to trust me) but resets don't annoy the admin.

3) Storing them encrypted with a "reset my password" feature that emails a new random password. Possibly the best of both worlds, but easily abused (you could continually reset someone else's password to annoy them).
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New 3)
bcnu,
Mikem

Eine Leute. Eine Welt. Ein F\ufffdhrer.
(Just trying to be accepted in the New America)
New 1)
We wouldn't annoy you on purpose, Scott...



;-)
jb4
shrub\ufffdbish (Am., from shrub + rubbish, after the derisive name for America's 43 president; 2003) n. 1. a form of nonsensical political doubletalk wherein the speaker attempts to defend the indefensible by lying, obfuscation, or otherwise misstating the facts; GIBBERISH. 2. any of a collection of utterances from America's putative 43rd president. cf. BULLSHIT

New Not for long, at least...
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New Is that a threat?!?
jb4
shrub\ufffdbish (Am., from shrub + rubbish, after the derisive name for America's 43 president; 2003) n. 1. a form of nonsensical political doubletalk wherein the speaker attempts to defend the indefensible by lying, obfuscation, or otherwise misstating the facts; GIBBERISH. 2. any of a collection of utterances from America's putative 43rd president. cf. BULLSHIT

New You should know by now...
I don't make threats. ;-)
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New 3, with verification
Provide an answer to some question, like "what is the name of my favorite sysadmin?" to get the password reset.

(of course, the question and the answer are in user profile)
--

This guy's ahead of his time! He's using quantum programming methods: in universes where invalid data is passed to this function, it does not return. Thus you are ensured that you will only have valid data after calling it. Optimally you'd destroy the universe on failure, but computers haven't quite advanced to that level yet.

-- [link|http://thedailywtf.com/archive/2004/10/26/2920.aspx|The] Daily WTF

New Seconded.
-YendorMike

"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
- Benjamin Franklin, 1759 Historical Review of Pennsylvania
New NO
You have then effectively reduced the security of the system to answering the stupid, weak secret question. DO NOT PERPETUATE THIS METHOD OF INSECURITY.
New Er, buh?
The security isn't compromised. The question would ONLY be used to allow someone to reset the password to a random string and email it, not get into the system.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New That's enough of a detriment not to warrant the risk IMO
New ?
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New ??
===

Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
New Yeah
When setting up a user, leave the "Question" and "Answer" fields both blank. Allow the user to enter their own question. And, of course, the answer to it.

"What is your Fraternity initiate number?" "1234"
"What is your favorite sports team?" "Chicago Cubs"
"What is the value of 6 x 9 on alternate Tuesdays?" "54"

etc.

When the user wants to reset their password, they are then prompted with their own question, must provide the correct answer, and then their password is successfully reset, and their new password is emailed to the email address on file, and nowhere else.

How is that insecure?
-YendorMike

"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
- Benjamin Franklin, 1759 Historical Review of Pennsylvania
New How is that insecure?
You've reduced the work needed to perform a successful attack because people do not know how to choose secure questions or answers. Although there are potentially trillions of answers to "What is your favorite sports team?" (including answers such as "Zaphod Beeblebrox" and "suo48gn4lo"), the majority of users will select from a limited list of answers, and a substantial portion are going to choose "Chicago Cubs".
New You're unclear on this.
They cannot either get into the system or get the password by knowing the answer to the question. They can only cause the user to get their password to be reset. I really don't understand your objection to this. Why don't you explain how you think this compromises the system?
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New See below.
New You only need one field labeled "Hint"
You can put a cryptic memory jogger that nobody else would figure out. I like that one. ie - "Your uncle's horse".

Precious few people are going to know my uncle's name, much less the name of his primary steed (he has half a dozen but one fave).




"The significant problems we face cannot be solved at the same level of thinking we were at when we created them."     --Albert Einstein

"This is still a dangerous world. It's a world of madmen and uncertainty and potential mental losses."     --George W. Bush
Expand Edited by tuberculosis Aug. 21, 2007, 06:13:52 AM EDT
New Sure...
...That's the smart-man's way of handling a user-enterable "hint" and "hint response" type of field. You could just as easily enter "Glarble fark?" for the hint, and "Farkin-a!" for the response. Who the hell would think of that response to such gibberish?

The main point is that a user-enterable password hint and response are more secure than choosing from a list of questions, with a corresponding pre-chosen list of answers.

PS- Sorry if I've now ruined your response to some website. Farkin-a! :)
-YendorMike

"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
- Benjamin Franklin, 1759 Historical Review of Pennsylvania
New Bah.
Now I need a new one...
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New Not quite
1. Never get involved in a land war in Asia.
2. Never confuse "secure" with "securable"--that is, "potentially secure".

The main point is that a user-enterable password hint and response are more secure than choosing from a list of questions, with a corresponding pre-chosen list of answers.


That should be:

The main point is that a user-enterable password hint and response are more securable than choosing from a list of questions, with a corresponding pre-chosen list of answers.


The difference is that most users will still choose easily-guessable questions and answers. You and I may not, but we're exceptional people. ;)
New And my point is...
The difference is that most users will still choose easily-guessable questions and answers. You and I may not, but we're exceptional people. ;)
I really don't give a rat's ass if anyone else chooses "What color is the sky?" with a response of "blue" to that question. If you let them choose the question and provide the answer, and they do something as downright stupid as that, why should I give a flying fuck? Why should Scott give a flying fuck, either?

I know plenty of people, both friends and cow-orkers, who choose things like their child's name for their password. I'd be willing to bet that at least some people here are guilty of same. Hell, even I have been known to reuse passwords from one website to the next. Every person is responsible for their own account's security under this method. That's the point.
-YendorMike

"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety."
- Benjamin Franklin, 1759 Historical Review of Pennsylvania
New I have a standard formula I use for passwords.
  1. Expendable accounts that are nice to have but nothing to important that I can't replace if compromised.
  2. Expendable accounts that are very important to me, but not irreplacable
  3. Important stuff that would be a troublesome to replicate or recover>/li>
  4. Critical stuff that, I will not be able to recover or replace or is so important to me that losing it would be very very bad.
Of course there are combinations of those levels.

I still like my idea. I very much prefer it. Even compared to /. and the mechanism used.
--
[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 I also have a standard formula
I assume that the web is open for all to review so have reused thae same password combo for years as I dont give too much of a rats if one gets compromised. I dont use ebay or other ecommerce sites. I do bank on the web so have a completely separate line for that. Knowing my generic work/web login would give no clues to my financials.
regards,
daemon
that way too many Iraqis conceived of free society as little more than a mosh pit with grenades. ANDISHEH NOURAEE
clearwater highschool marching band [link|http://www.chstornadoband.org/|http://www.chstornadoband.org/]
New Ding, Ding, Ding.
If you fingered out my expendable passwords... you are completely in the wrong secotr of the galaxy to try to relate to my "secure" passwords.

So it sounds like you are the same kind.
--
[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 It's only insecure if the user is allowed to proceed
as if they had given the correct password.

Imric's Tips for Living
  • Paranoia Is a Survival Trait
  • Pessimists are never disappointed - but sometimes, if they are very lucky, they can be pleasantly surprised...
  • Even though everyone is out to get you, it doesn't matter unless you let them win.


Nothing is as simple as it seems in the beginning,
As hopeless as it seems in the middle,
Or as finished as it seems in the end.
 
 
New Bah. Risk is the issue.
...and there are more risks than simply "proceeding as normal". One is that they would (in parallel) gain access to the new-password mailbox through sniffing, cracking or other means. Another is that they mount a DOS on my mailbox through the "new password" feature. For some mail systems, these would go hand-in-hand. Secure systems require examining all the risks, not just the original risk for which your technology was designed.
New So what's YOUR suggestion?
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New Unfortunately for you #1 ;)
But looking at #2, it should be possible to secure the plaintext pword DB on a limited-services box. If the server also does FTP, SSH, what-have-you, it becomes less desirable.
New WTF?
How is #2 any more secure than #3?
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New Sorry. You're right. I didn't read carefully.
I glossed over the email part.
New So how does that change your answer?
And I'm mainly interested to see if you have any suggestions for automated functionality.

But if we were to do #1, there's still the issue of me authenticating requests for password changes (if I'm doing the changing) or email snooping if I'm resetting and sending a new one.

There's also option #4 at the end of the thread.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
Expand Edited by admin Nov. 30, 2004, 04:48:36 PM EST
New Same risk than we have now during login.
And with CRCs suggestion that there be a limit on tries/hour, a DOS on your mailbox is NOT an issue.


Imric's Tips for Living
  • Paranoia Is a Survival Trait
  • Pessimists are never disappointed - but sometimes, if they are very lucky, they can be pleasantly surprised...
  • Even though everyone is out to get you, it doesn't matter unless you let them win.


Nothing is as simple as it seems in the beginning,
As hopeless as it seems in the middle,
Or as finished as it seems in the end.
 
 
New Same outcome, different risk--the attack surface has doubled
New Not mine.
"The other" Scott's: [link|/forums/render/content/show?contentid=185579|Post #185579].


   [link|mailto:MyUserId@MyISP.CountryCode|Christian R. Conrad]
(I live in Finland, and my e-mail in-box is at the Saunalahti company.)
Your lies are of Microsoftian Scale and boring to boot. Your 'depression' may be the closest you ever come to recognizing truth: you have no 'inferiority complex', you are inferior - and something inside you recognizes this. - [link|http://z.iwethey.org/forums/render/content/show?contentid=71575|Ashton Brown]
New Can we please weight the risks
against benefits and against the importance of the information being protected? I have hard time imagining someone using mailbox spoofing just to get access to my IWETHEY identity. DOSes can be easily prevented by limiting the number of resets per day.
--

This guy's ahead of his time! He's using quantum programming methods: in universes where invalid data is passed to this function, it does not return. Thus you are ensured that you will only have valid data after calling it. Optimally you'd destroy the universe on failure, but computers haven't quite advanced to that level yet.

-- [link|http://thedailywtf.com/archive/2004/10/26/2920.aspx|The] Daily WTF

New 3) with some safeguards?
We certainly want to minimize annoyance of the admin. :-) Security is nice to have, but probably not essential here.

It seems like 3) is the way to go. But maybe try to minimize the potential for abuse by only permitting it to be reset once a day or once a week or something. Asking for the answer to a "hint" before giving out the password is another option, but what if one forgets the answer to that too? :-/

Perhaps cheap biometric sensors will make this moot. Until, that is, we all have Lasik eye surgery and burn off our fingerprints anyway... :-(

Cheers,
Scott.
New 4) WikiWay: everything wide open ... muuuaaaahahahahahaha
===

Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
New Shaddap wid' yer shaddin' ap...
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New 3 with a "what is your dog's name?" thingie
-----------------------------------------
How do you convince a Washington Journalist that you're not slapping him in the face?

Tell him you're not.
New I'll join Ark, Scott(2), Don(Silverback), and YendorMike: 3+
Where the "plus" is getting the answer to some simple user-defined question right. Sure, this might lead to *some* incidence of "1", when some fuckwit forgets his Q&A... But a lot less than if "1" were your only option. And, face it, however much you automate something, you're going to want (need?) a manual override as the ultimate fail-safe, anyway. (Oh, and why not, like someone suggested, a "Max [x] times per [time-unit]" limit *too*, while ye'r at it! :-)


   [link|mailto:MyUserId@MyISP.CountryCode|Christian R. Conrad]
(I live in Finland, and my e-mail in-box is at the Saunalahti company.)
Your lies are of Microsoftian Scale and boring to boot. Your 'depression' may be the closest you ever come to recognizing truth: you have no 'inferiority complex', you are inferior - and something inside you recognizes this. - [link|http://z.iwethey.org/forums/render/content/show?contentid=71575|Ashton Brown]
New <raises hand> on that last bit. :-)
New Aye - 3) with
a limit for retries / time-interval sounds like the best solution to me, too.

Imric's Tips for Living
  • Paranoia Is a Survival Trait
  • Pessimists are never disappointed - but sometimes, if they are very lucky, they can be pleasantly surprised...
  • Even though everyone is out to get you, it doesn't matter unless you let them win.


Nothing is as simple as it seems in the beginning,
As hopeless as it seems in the middle,
Or as finished as it seems in the end.
 
 
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..."
Expand Edited by admin Nov. 30, 2004, 04:50:29 PM EST
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.
New how about 4, the way we do it now
doesnt annoy the admin at all I dont think
regards,
daemon
that way too many Iraqis conceived of free society as little more than a mosh pit with grenades. ANDISHEH NOURAEE
clearwater highschool marching band [link|http://www.chstornadoband.org/|http://www.chstornadoband.org/]
New Which is?
1) Run away and not post anymore? :-<
2) Create a new user ID?
3) Get zIWeTheyer drunk at BP Bash and assume their identity?
4) ?

Cheers,
Scott.
New And what would that be?
Because it doesn't fscking work right now. :-P

That would be option #6, anyway, once you tell us how it's *supposed* to work now.
Regards,

-scott anderson

"Welcome to Rivendell, Mr. Anderson..."
New the way it works now
example

ben.tilly
BTilly
broomberg
broom2

etc
now for a large board, assuming you are doing a rewrite, I would do the following
supply a generated key that will show only during initial setup, with instructions to print the key and keep it safe, if a client wants a password reset he must supply the key and the original email address that they signed up with, then allow them to reset it. If they cant remember that combo have them call customer service :-)
regards,
daemon
that way too many Iraqis conceived of free society as little more than a mosh pit with grenades. ANDISHEH NOURAEE
clearwater highschool marching band [link|http://www.chstornadoband.org/|http://www.chstornadoband.org/]
New How about 5...
...Set your browser to remember the userID and password for this login prompt?




...Oh, you're using Insecure Exposer?!?

...too bad...no pswd for you!
jb4
shrub\ufffdbish (Am., from shrub + rubbish, after the derisive name for America's 43 president; 2003) n. 1. a form of nonsensical political doubletalk wherein the speaker attempts to defend the indefensible by lying, obfuscation, or otherwise misstating the facts; GIBBERISH. 2. any of a collection of utterances from America's putative 43rd president. cf. BULLSHIT

New 16) Storing them encrypted with a "reset my password" featur
16) Storing them encrypted with a "reset my password" feature that emails a new random password reset URL. That URL times-out after 24-36 hours or gets removed if another request is made during the timeout period. If the URL never gets used, the reset never happens, but if it does get used, the password is reset by the requestor on that page. Also, limit the number of requests per day, to evade a Mail DoS.

I hate reminder based password crap, never want someone to have to service my own problems. Let me take care of mine.
--
[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]
Expand Edited by folkert Nov. 30, 2004, 06:38:09 PM EST
New A variation on 2)
If the other arguments for/against do not persuade there is a variation on #2 that /. appears to use.

They'll email you a temporary password that doesn't become active until you use it. This defeats the "change someone else's password to annoy them" attack.

But I vote for #1
--
Chris Altmann
Expand Edited by altmann Nov. 30, 2004, 07:36:03 PM EST
New 3), with a question 1st.
New 3 with a proviso
The current password should be retained until such time as the user logs in with the new password. IOW, anyone can request a new password be sent to my email account, but until such time as I log in with the new password, the previous password remains in force. Means anyone can request to reset my password without my having to take action.

Basically means you have an (a) active password; and (b) reset/reserve password. The reserve password will expire within a limited time period.

Other proviso should be that no more than 1 request can be made per day for a password reset. Don't want someone mail-bombing our email via z.
New I like that!
--

This guy's ahead of his time! He's using quantum programming methods: in universes where invalid data is passed to this function, it does not return. Thus you are ensured that you will only have valid data after calling it. Optimally you'd destroy the universe on failure, but computers haven't quite advanced to that level yet.

-- [link|http://thedailywtf.com/archive/2004/10/26/2920.aspx|The] Daily WTF

New 3. Puts the onus of keeping valid email address on user.
Alex

In politics, what begins in fear usually ends in folly. -- Samuel Taylor Coleridge, poet (1772-1834)
New 3


Peter
[link|http://www.debian.org|Shill For Hire]
[link|http://www.kuro5hin.org|There is no K5 Cabal]
[link|http://guildenstern.dyndns.org|Home]
New 6.
It's very like 3, but the URL is required to "follow-through" on the reset.

Incidentally, EzBoard uses #2. I occassionally get emails from them with my current userid and password; usually whole months go by without any. I think the most I ever had was 3 in one week. I figure most of them are people trying to register the same userid as me and not realizing that EzBoard has told them "it's taken - pick another".

Wade.

Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed
 
Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please

-- "Anything but Ordinary" by Avril Lavigne.

New "zIWT meta: Which is better:" Voting/Ratification (new thread)
Created as new thread #186086 titled [link|/forums/render/content/show?contentid=186086|"zIWT meta: Which is better:" Voting/Ratification]
--
[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]
     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)

For those of you not versed in fine dining lingo, that is: Potato Bacon Cheez, fried noodle pockets, fried cheese, grease bread, cream cheese dip, chicken fingers, and fried fry.
349 ms