251–260 of 376 posts
Earlier quoted context omitted.
Can you actually attach an MX record to a tld?
https://gist.github.com/ddol/1445736
Earlier quoted context omitted.
Not true, they most likely convert all characters to a certain case before they hash it, so even if you entered PASSworD123 they convert to password123 and then hash. I believe I read that Facebook stores a few commonly mistyped versions of everyone's password. Actual password, typed as if caps lock was on, things like that.
That reduces password entropy and makes the hashes easier to crack.
Earlier quoted context omitted.
How about case insensitive passwords? That one always bugs me because it suggests that maybe they are storing the password.
I've seen people write hash functions which change the input to all lower or upper case first. I think it's a pointless, stupid idea– maybe unless it's a VERY low-risk system for people with cognitive disabilities, kids or seniors– but not necessarily unhashed-password-level stupid.
Earlier quoted context omitted.
Cameras are everywhere in public spaces, and most people wouldn't notice a password field wasn't obfuscated until they've already started typing. Defaulting to obfuscated seems the only sensible option.
But with a camera I can just see what you typed, with a fairly high accuracy.
If you are pasting passwords, you are really using an ad hoc third-party SSO authentication provider (which may or may not also use the equivalent of 2FA) via a manual token-exhange mechanism. Better than allowing pasting passwords, just support OpenID or some similar federated authentication solution, which does the same thing without manual token exchange and the attendant opportunities for errors. You might want t…
Think of it this way: passwords are a more standard API than OpenID. Since passwords are the standard, they are "implemented" by all your clients. That cannot be said for OpenID.
Even worse: sites that silently truncate your pasted password to the maximum length. When all you see is those little dots and the password is wider than the text field, it's very difficult or perhaps even impossible to tell how many characters were successfully pasted. And obviously truncation sets you up for disaster when you try to log in using your saved password and it just doesn't work.
Earlier quoted context omitted.
But that's not a feature of email in general. That's a feature of gmail, and a few other email providers that have followed suit. For email in general, foo@bar.com and foo+baz@bar.com are distinct emails that may go to different users.
I wouldn't say "a few other email providers that have followed suit". As far as I know, that's always been a feature of Postfix, and common with Sendmail before that. And qmail offered "-" for the same purpose (as well as providing a facility for filtering/redirecting mail based on -extensions).
While I believe the + was common for postfix, exim and sendmail?
There even was a spam-fighting scheme that used this - it took a key, and optional date, and a sender address - and generated a unique address you could give out, that was only valid for a certain time, for a certain set of senders.
If the system received a mail with a from address that didn't match the cryptologically signed to-address (e12e-xjjgff65477fc@example.com) - the mail was held back, and the system generated a reply, with a signed reply-to address. A sort of manual grey-listing.
If you are pasting passwords, you are really using an ad hoc third-party SSO authentication provider (which may or may not also use the equivalent of 2FA) via a manual token-exhange mechanism. Better than allowing pasting passwords, just support OpenID or some similar federated authentication solution, which does the same thing without manual token exchange and the attendant opportunities for errors. You might want t…
>ad hoc third-party SSO authentication provider (which may or may not also use the equivalent of 2FA) via a manual token-exhange mechanism This is a huge step up from a memorized password. Go ahead and implement OpenID too, but don't force people down to the level of memorized passwords needlessly. Expending effort to prevent pasting is a stupid move.
Oh, I agree. I was more talking about people who have already expended that effort (so its zero marginal effort) and are considering reversing it (which as a small but non-zero cost.)
In general, more and more sites encourage me to just leave Javascript turned off all the time. If they break, screw them, I'll go elsewhere. The only sites "sticky" enough to make me put up with it are financial, and that's only because they all suck so changing solves nothing. 'Missing out' on Angular sites hasn't left me feel like I'm missing anything in my life. This ties in to the discussion of Craig's List the o…
I also use extensions to enable them on certain sites. Just tap the extension icon and it will reload with JS enabled.
You'd be surprised how fast webpages load without JS
Earlier quoted context omitted.
Not allowing + in an email field is one of my pet peeves. Congrats on finding an amazing-looking regex for email validation instead of thinking about it.
well, string+{whatever1}@gmail.com mails are redirected to string@gmail.com. So a user can just open account for string@gmail.com and then use that to open thousands of user accounts on the site that allows "+" on the email field. (I used to do this on sites that allowed limited number of free downloads after which you had to pay)
example+Youre+the+best!+Around!+Nothings+gonna+ever+keep+you+down@gmail.com
Too bad the music emoji is stripped by HN!
PS: Emoji in titles also make things like Youtube videos and blog posts pop quite a bit when shared via social media.