81–90 of 113 posts
"Or provide a single use single action token that performs one function, like confirm friend. Security doesn’t need to be all or nothing."
For extra security this token can be one time useable only.
The real point is: don't do two-level ACL on websites. At my previous company we had these "auto-login" links in emails and they are extremely powerful. But maybe once every six months people would call or write in and say "I forwarded a job posting from one of your email alerts to a friend and they had full access to my account!" and we'd have to revisit the issue again, but the conclusion was always the same - we w…
The reason so many sites prompt for password is for security. Yes, they will also send you an email with a link to reset the password to the same address. However, the difference there is that you will know if someone has changed your Foursquare password and the token used to allow for a password change can be expired immediately after the change takes place rather than offering continued access. With the OKCupid sys…
> I'm not saying that there aren't low-security services where this convenience is good. It's more that the author hasn't taken into account that there is greater security in the forgot password system. Exactly. And I think it's somewhat dangerous for the author of the article to not understand this important distinction and at the same time advise creators of web apps to implement this behavior. Judging by the amoun…
If you create a blog, don't use fixed headers and footers that take up half a netbook's screen.
yes. I use space to move the content up a screen, and layouts like this mean I then have to go and scroll back a few inches.
I haven't looked into this, but if anyone has a fixed position header on their project, they should look into overwriting the space bar action readability-style and calculating how far to jump down.
Earlier quoted context omitted.
> I'm not saying that there aren't low-security services where this convenience is good. It's more that the author hasn't taken into account that there is greater security in the forgot password system. Exactly. And I think it's somewhat dangerous for the author of the article to not understand this important distinction and at the same time advise creators of web apps to implement this behavior. Judging by the amoun…
It's getting upvotes because the title says "don't do this". People are voting for the fact that the article is offers bad advice. The author however doesn't seem to have quite grasped this - thanking us for his position on the HN front page!
1. Set a short expiry date on the link (1 day). 2. On first click within 1 day, log user user in and expire link. Ask user if they want to stay logged in (via a subtle overlay at the top of the page perhaps + set "remember me" cookie) 3. On subsequent clicks within 1 day. If user has "remember me" cookie, log them, otherwise redirect to login screen. 4. Clicks to link after 1 day. Redirect to login page.
This should be just about as safe as a forgotten password email; they both have an expiry period + 1 time use, meaning anyone intercepting the email before the expiry and before the user clicks on it can impersonate the user.
The only counter-point that I'll make against my own point is that a forgotten password email is sent on demand, i.e. a user requests it, so they are probably more likely to click it immediately (hence expire it immediately).
I wouldn't do this for an e-commerce or otherwise sensitive app, but for something a bit more casual I think it would ok.
Earlier quoted context omitted.
Not to also forget that if you have automagic login links in the email, you can no longer forward that email to anyone without compromising your account. Try educating end-users on that one!
Simple solution: put a persistent cookie on the computer of everyone who's ever logged in. Automatically log the user in if this cookie is present and the URL is correct. Obviously, the cookie should be unforgeable - e.g. HMAC-SHA1(service_secret_key, username).
However, that falls over with people who have Display Images turned off AND don't click through to the website before they forward it. But if you HAD to do this feature, it would help a little.
"Forgot your password" requests usually POST to the web server, not GET (what's usually used in emails). Sending links that give you complete control over the account by default seems like an extraordinarily bad idea--as does allowing users to reset their accounts without any kind of identity verification. (You could do a POST from an HTML email, but then, in most email clients, the users would be prompted with "You…
POST can be sniffed and is only slightly less vulnerable than GET. HTTPS at a dedicated address should be a minimum level of security for a login form. Anything else is readily vulnerable to sniffing or spoofing.
The real point is: don't do two-level ACL on websites. At my previous company we had these "auto-login" links in emails and they are extremely powerful. But maybe once every six months people would call or write in and say "I forwarded a job posting from one of your email alerts to a friend and they had full access to my account!" and we'd have to revisit the issue again, but the conclusion was always the same - we w…
amazon does that. you can browse the site and it identifies you and your preferences, but when you go to check out or modify account settings, you have to enter your password.
And then there's Windows Live. Click on anything remotely related to Passport? You need a password (followed by 17 redirects, which is hilarious when managers have sound turned on and you here the "click click click click click" as IE bounces around).
The real point is: don't do two-level ACL on websites. At my previous company we had these "auto-login" links in emails and they are extremely powerful. But maybe once every six months people would call or write in and say "I forwarded a job posting from one of your email alerts to a friend and they had full access to my account!" and we'd have to revisit the issue again, but the conclusion was always the same - we w…
amazon does that. you can browse the site and it identifies you and your preferences, but when you go to check out or modify account settings, you have to enter your password.
It's definitely tricky to implement (how do you determine whether a user is "sort of logged in"?), but once you get over the conceptual hurdles it's a pretty awesome user experience.
However, I would argue that like much of what Amazon does, it's not necessarily appropriate for the majority of sites.