Password reset situation
-
I'm implementing the password reset functionality for a side project. I'm doing this with the "Email a generated link" approach. To do this, I'm generating a random token and store it in the database and send the user the link, i.e.:
http://acme.com/reset?email=a@æ.com&code=1234tokenWhich signs in the user and presents a password form... once.
Now, the question is: while I have this reset token stored in the database, should I allow the user to sign in or completely lock them out until they finish the process?
-
Don't lock them out, since that would provide a trivial mechanism for the malicious to stop someone from logging in.
-
Very good point
-
My general suggestion would be: try to figure out how other big sites do it, and do it exactly the same way.
-
Also half the time all I need is the correct formatting of my username which the reset functionality provides. Then I can just log in instead of being forced to change my password.
-
Also half the time all I need is the correct formatting of my username which the reset functionality provides.
Or, back in the days before I started using KeePass, what the site's stupid rules for password maximum length and forbidden characters are, so I remember which variation of the common password base I used on that site.
-
My general suggestion would be: try to figure out how other big sites do it, and do it exactly the same way.
Sooooo, you are saying he should just store passwords in plain text in the database and then just email people their password if they forget it?
-
Sooooo, you are saying he should just store passwords in plain text in the database and then just email people their password if they forget it?
Well, it beats the post-its used by small sites…
-
Don't forget to truncate long passwords differently on the password reset and login pages.
-
stupid rules for password maximum length
store passwords in plain text in the database
truncate long passwords differently on the password reset and login pages
I'm doing none of that.
-
-
I notice you didn't deny "stupid rules for ... forbidden characters."
-
Don't lock them out, since that would provide a trivial mechanism for the malicious to stop someone from logging in.
Also, make sure that the token has an expiration. You don't want it just sitting in someone's email as a forgotten vulnerability. In setups like this, I've generally seen them expire after 24 hours.
-
Well, you cannot build ongoing income for "maintenance charges" unless you program in some tomfoolery. You can't build lasting income if you do it right the first time.
-
I've generally seen them expire after 24 hours.
We want super security. They should expire after 42 seconds.
-
Exactly why 42? Some literal reference?
-
Exactly why 42? Some literal reference?
Really? You have some homework to do or else we are going to call for revocation of your nerd credentials.
http://en.wikipedia.org/wiki/The_Hitchhiker's_Guide_to_the_Galaxy
-
We want super security. They should expire after 42 seconds.
In reality, don't do that. Some people's email can take hours to deliver. One of my colleagues has this problem, which is ridiculous as my email comes through rapidly to the same Exchange server. Whatever's going on, it's strange. It's like his email is selected for special TSA processing every time…
-
-
I know why 42, I didn't know why you used it in as some random value. Or you write stuff like:
def randomInt() { return 42 //Because of THGG }
-
int randomised = rand.Next(42);I actually wrote this a few weeks ago. It was part of a project for some internal training assessment, not production code.
-
-
I actually thought he wrote NSA
-
Expanding the quote shows the unfixed quotation: TSA.
-
I actually wrote this a few weeks ago. It was part of a project for some internal training assessment, not production code.
That's what you think. Someone will reuse it in the future and it will end up a front page article.
-
I notice you didn't deny "stupid rules for ... forbidden characters."
Sorry, no dwarf clerics allowed.
-
My general suggestion would be: try to figure out how other big sites do it, and do it exactly the same way.
Which is, generally, what was described above: the new password link should not lock you out, in case you remember the old one in the meantime.
-
Well, you cannot build ongoing income for "maintenance charges" unless you program in some tomfoolery. You can't build lasting income if you do it right the first time.
Let me introduce you to SaaS.
-
Coming soon: a company offers to look after your cloudy stuff for you, and we have SaaSaaS.
-
-
Needs to be a catchier term for marketing drones. Cloud2 or some shit.
-
something like this?
The /etc/bus
Back in the early 90's, Steve worked at a certain blue company known for its putty colored machines that cost a lot of green. This company was trying to make a big splash for itself in the UNIX market and wanted to convince technical folks that they "got it." And Steve had just the idea to help...
@pjh @apapadimoulis bug report? the main site doesn't onebox!
-
-
-
Cloud2 or some shit.
Actually, Cloud∞ would actually work as a product name, but the only
suckerdevelopeneur I know who would actually take that on is totally burnt out right now though from his last project.
-
@pjh @apapadimoulis bug report? the main site doesn't onebox!
Iframely URL Debugger - Open Graph, Twitter Cards, oEmbed
Check your URL against Open Graph, Twitter Cards, oEmbed specs. See what other apps see.
-
ahh... oembed not supported....
who wants to issue a PR?
:-P
-
Don't you SaaS me, boy!
-
Oh no he didn't!
