181–186 of 186 posts
>> When users sign up, you should e-mail them with a link that they need to follow to confirm their email I'm curious, why is this good? Sure, sending an email to them so they confirm they have the correct email, but what is the benefit of the verification step? Is it to prevent them from proceeding in case they got the wrong email? It would be nice if this was justified in the article. I would also add, that changin…
>When storing passwords, encrypt them Nopenopenopenopenope! This is terrible advice. Don't do this. Remember what happened when Adobe did this?
I hope that at least some services will eventually consider that for sites that aren't storing valuable data, Passwordless (i.e. emailed, etc. one-time token) and long-lived session tokens are better than even touching passwords.
And if you want the user to be able to perform sensitive operations (edit their personal details for example) then you'll have to ask for a OTP or email verification every time. These methods tend to be higher friction than a password box.
Earlier quoted context omitted.
> JavaScript is an integral part of the platform that is the web, just like HTML and CSS I always think it's interesting when people bring CSS into this, because it's actually a very strong counter to the general argument. By design a user agent is well within its rights to completely ignore any stylesheets attached to a page, and the idea was always that this should be completely OK, partly because you have no idea…
You are correct all the way. The problem is that arguments from both sides are often generalized and it's not necessarily wrong. If you have a wide audience e-commerce enterprise you should probably keep JS use as limited as possible. If you build tools for programmers or highly dynamic projects, JS everywhere is probably fine.
Earlier quoted context omitted.
"if you care about interactivity, responsiveness, and general user experience" A simple web page (no-js) in a browser covers these three things to a highly acceptable standard. It's when you start to add the other junk that these three become compromised. For example: Interactivity: Hyperlinks work great from HTML 1.0 onwards Responsiveness: Without additional items like JavaScript or even CSS, web pages are incredib…
What is ISO-3306?
Earlier quoted context omitted.
I hope that at least some services will eventually consider that for sites that aren't storing valuable data, Passwordless (i.e. emailed, etc. one-time token) and long-lived session tokens are better than even touching passwords.
Going passwordless with long-lived sessions requires more complex session management though. If you don't time-out sessions then you increase the cumulative probability of a live session eventually being hijacked through XSS, MITM (coffee shop, rogue wifi), or malware etc. And if you want the user to be able to perform sensitive operations (edit their personal details for example) then you'll have to ask for a OTP or…
Sure you don't want to constantly bug the user but not every site needs to do that. Especially for sporadically-used sites, "receiving email" could be less of a pain than keeping track of passwords.
A session can be long-lived without being indefinite. We might decide that any authenticated site visit within the last week is new enough not to repeat the passwordless process, or we might say two weeks or a month or whatever.