Hacker News Reader

Comment by thesuitonym | Hacker News Reader

Other signs that a site was built by incompetent developers (Or had too much management interference--Devs aren't always to blame!):

Only works with Internet Explorer

Doesn't work with Internet Explorer

Password must have one of 4-10 special characters, but not other special characters. (e.g.: Must contain !, @, ^, &, or parentheses, but not ;, ", etc)

Passwords have no requirements

Right-click is disabled

Video plays as soon as the site loads

Share buttons that use javascript to follow the viewport

Share buttons that pop up over every single image

"Want to see more" when you move the mouse to the top of the screen (Or reach the bottom of the page) (or as soon as the page loads)

Slideshows of any sort

View on HN

We had a gem at my last university (UCL): you must rotate your password every few months, your password can't be anything like any of the previous ones (i.e. previous ones are stored, and they're not hashed), your password must contain special characters etc.

Except.. it can only be 8 characters long. Anything else gets truncated (they explicitly said so). The mind boggles.

I have no idea where this limitation comes from, do people just set an 8 character field in their database? Was this a problem decades ago that they figured they'd save a few megabytes of storage space?

I think they've finally changed it so that the reset period is determined on your password complexity, no length limitations, and you can have 2FA (or at least mobile password reset).

> your password can't be anything like any of the previous ones (i.e. they're not stored hashed)

That's... not necessarily the case. You can implement that check by only storing hashes of previous passwords, or of patterns derived form them that are also forbidden (e.g. store a bcrypt of every previous password converted to all lowercase and with numbers and symbols removed).

Doesn't that decrease the benefit of storing a hash? You probably know the process through which the derivative hashes are generated, which is not known-plaintext but seems kinda iffy still.

I think it would decrease the benefit, yes.

If you store the hash of the password, plus the hash of a hundred "similar" passwords, then the hacker only has to brute-force one to find that they are on the right track, and then brute-force "similar" combinations.

Unless you do it the other way around: Generate a list of all passwords similar to the one the user just entered and see if that matches any previous hashes. This is how Facebook's password check works [0]

[0] https://security.stackexchange.com/a/53483

Supposedly, you'd only be able to get feedback about the similarity of a password in a state where you're already authenticated. So I guess this would help an attacker get the password when they've already gained access in some other way. But that's a big assumption.

Though I'm pretty sure I've seen "Your password is too similar to a previous password" before, which suggests some kind of plaintext Levenshtein distance check.

"Is the same as" can be fine with a hash, but "Is too similar" is definitely a red flag.

When I've seen that "your password is too similar..." warning, it was with a system that required entering my current password to set a new password, so no need to store a previous version in plaintext.

Though another way around it is to apply a set of common transformations to your new password, hash it and see if it matches the previous one. I.e. if your current password is "Password123" and you try to set it to "Password1234", the system could truncate the last digit on the new password and see if it matches the current one.

I think almost every system requires you to put in your current password to change new password.

Aren't passwords hashed on the client side before sending it across the network? That would make your way around not work (unless that's done on the client side also after verifying from the server that it's correct).

I've certainly never encountered a web app that hashes locally before sending. I suppose it could work if this was at the account creation or password management stages, but you couldn't implement it at the login stage for obvious reasons.

I'm having trouble imagining what scenario client-side hashing would protect against.

Man in the middle attacks fetching for plaintext passwords

-- edit: using a KDF would improve it even more.

If the client only sends the hash to the server, a MitM also only needs to capture the hash.

Sure, but if they've MITM:ed your trusted certs, aren't you already boned in so many ways?

Hashing it on the client side will make the hash the password. So the stored hash can be used as password by turning off the client side hashing, for instance by turning off javascript. You use https to avoid sending the password in cleartext over the network

Yeah, they probably stored old hashes, but I find it hard to believe they stored variations of old ones as well. Maybe they did though!

You're certainly right (e.g. that's how Facebook can remember so many different variations of you password without storing the actual password itself), but if their engineers are capping the password field at 8 chars, I HIGHLY DOUBT that is what's going on.

Manager: We need to ensure people aren't using similar passwords on reset, but we can't store the password unhashed.

Developer: Similar passwords? Or Same passwords. Similar is hard.

M: Similar. Can't let people be lazy with their passwords.

D: Well, if we really have to do it, I guess we could store a bunch of hashed variations of the password, but...

M: Good! Let's do that.

D: ...but that could be a massive amount of space for long passwords.

M: Okay, we'll just enforce short passwords then.

D: ...doesn't that more than negate all the benefit of preventing similar passwords when rotating them?

M: Doesn't matter, the CEO said he wants this. Hop to it!

Developer laments the stupidity of their life

Been there, fought that.

longer passwords don't hash to longer values (within any reasonable variation of order of magnitude in input size). That would defeat the purpose of hashing

But a longer password would require more combinations for similarity than a short password.

Yes, that's the point being made.

Ah. Thanks for clarifying.

Still, permutations longer hashes don't require substantially more space. Password storage is a completely trivial fraction of total storage -- Compare to a single photo, or a video!

And further still, they don't need to _store_ all the hash variations

https://security.stackexchange.com/questions/53481/does-face...

Wow, it slipped my mind entirely that you could do the permutations when you create the new password but before verifying, rather than after creating a password. That's a great idea, and embarrassingly obvious in retrospect.

Why would they need to store the hash for all the combinations?

Why not generate a list of similar passwords to the new password, hash them all using the same salt of the previous password and then compare them.

Depending on what is considered "similar", every extra password character may exponentially increase the number of similar passwords.

Well in my case, there was only an 8 character limit, so there was a least a bound on it. I didn't investigate how far you could deviate from an old password before it was allowed though.

It's funny because "DecemberSixteen" is very different from "MarchSeventeen" as a password from a characters point of view but is trivial to extrapolate if you know the guy has to change password every 3 months.

If you really want to annoy me, use soundex[1] as a final normalization step.

[1] https://en.wikipedia.org/wiki/Soundex

That's unnecessarily complex. Just ask for the old password when doing an expiration reset. Validate the old one then compare that against the proposed new one.

Actually, that's a very good point - you did indeed have to submit the old and new passwords. I want to say that they checked against older passwords too, but I might be misremembering.

That doesn't help. Your new password might be the same as the twice-previous password.

I guess it comes from old UNIX passwords (80s and before). They were limited to 8 characters if my memory doesn't fail me. But they were already stored with one way encryption.

Your memory's fine.

man 3 crypt => https://linux.die.net/man/3/crypt

Thanks.

That prompted me to google up a summary of the password length limits of various operating systems https://security.stackexchange.com/questions/22721/password-...

I once had similar problem in some ancient LDAP installation and it turned out that adding random 9th character was enough to pass the check while keeping the password effectively the same :)

Theoretically, using homomorphic encryption you can both store passwords securely and check them for similarity. :)

Comparing the hash values would also work (if done right, hash collisions are extremely rare).

If the similarity of ciphertexts reveals information about the similarity of the cleartexts, then given you have the encrypted password and the encryption algorithm, couldn't you guess the cleartext password by performing search? The point about hashes is that nobody can decrypt, although everybody knows the "encryption" algorithm. So not sure that homomorphic encryption would help in this case. Or am I missing something?

The most odd bit about that UCL password policy is that it said "your password change has been submitted and may take up to 24 hours to take effect." To this day I'm not sure if they were just displayed in cleartext and someone just typed them in by hand

I think some SSO systems actually have to sync the password up with all the crappy computer systems that use it (rather than using actual SSO) and that syncing is done on a cron job at 3am.

Britain and the Commonwealth feel especially bad with onerous and arbitrary requirements on passwords and such.

I have seen my online password for Australia's biggest Telco, in plaintext on a computer screen in the shop while buying a new phone...

I worked at a bank that still has online banking password requirement of 6 characters... though must contain a number so totally secure.

Internally they still use Lotus notes 7.? last I heard. And storage limit was something like 100Mb if I recall correctly.

My University also had an 8 character restriction. When I asked them about it, they said it was because they wanted a single password across all of the systems, and some of them were really old and had an 8 character restriction, so that had to propagate up to everything else.

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.

Yup. The most email validation I evern implement is "there must be an @ sign with stuff before and after the @ sign". Maybe require a dot in the latter space.

.+@.+\..+

That regex is defective. See benchaney's reply above.

.+@.+(\..+)?

should satisfy you both right? I use the original or a form of usually when I had to check emails.

Fully qualified domains actually end in a . If you're allowing sally@google then you must also allow sally@google. To be valid

No you don't. Email addresses explicitly require any periods in the domain to have at least one (non-period) character after the period. From RFC 5322, the relevant grammar production for the domain looks like

  dot-atom-text   =   1*atext *("." 1*atext)

(where atext is letters, digits, or a set of specific punctuation characters that doesn't include periods).

Ah, I wasn't aware that email addresses defined that differently. it looks like it's also the same way as part of obs-domain as defined by the addr-spec part of that. RFC 822 also seems to say the same thing, it's been way too long since i've tried to read those RFCs.

That's identical to just doing .+@.+

Thankfully my email is @@@@@@@.......

One (probably forgotten) reason people validated email addresses with convoluted regexps is that there are multiple (actually valid per RFC) email addresses formats that can do nasty things. Like explicitly specifying a series of mail servers to go through. They're (hopefully) deprecated and rejected by most servers nowadays, though.

> hopefully

Why?

> By default, this feature is turned off. This closes a nasty open relay loophole where a backup MX host can be tricked into forwarding junk mail to a primary MX host which then spams it out to the world.

http://www.postfix.org/postconf.5.html#allow_untrusted_routi...

Strictly speaking, the dot in the latter space isn't actually necessary. It needs to be a resolvable domain, but if you bought a TLD you could be "name@tld"

...is there someone out there who did this?

Not that I'm aware of. Although I wouldn't be surprised if google did it for their employees. They already own the google TLD, they could very easily make it point to the google.com emails.

How many HN-reading googlers have you just made to send 'Test' emails to themselves, I wonder!

I don't think an @domain is required if it's an email address on the same mail server.

That certainly used to work on Gmail; I haven't tried recently.

(Obvious caveat being that any provider can trivially append @provid.er if you don't specify, so this isn't really proof that email is specified that way.)

Wow, that is literally the only reason I would want a TLD

ICANN forbids application records at the apex of a TLD. The only TLDs that do funky things like this are ccTLDs.

And if you try to actually use a bare TLD you will crash hard into collisions with unqualifed domains and search paths. So, fun as a hack to amuse fellow techies but not useful for anything real.

Can you actually attach an MX record to a tld?

https://gist.github.com/ddol/1445736

Huh, cool. Though I don't see a lot of those records myself. For example, `dig MX ai.` gives me the MX record for ai., but I can't see any MX records for as., bj., or dj.

I know lots of developers (myself included) who thought they could write a functional email regex. Eventually you learn that in the end, the way to validate an email address is to send an email.

> Eventually you learn that in the end, the way to validate an email address is to send an email.

In my experience as a user, most people in the end also validate the email address by sending an email, but do no learning.

Allowing + in an email/password field, but failing to properly encode/decode it, is even more infuriating.

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)

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).

The point is that foo+bar is a convention that many providers follow and not an actual rule of email, and therefore blocking that doesn't make sense because you'll block legitimate addresses too.

Similarly, mail providers can come up with all sorts of different conventions if they want. For example, when setting up a new domain in FastMail, it offers the ability to accept anything@user.dom.ain and turn that into user+anything@dom.ain, and it offers user@anything.dom.ain which it will deliver to user@dom.ain. So here we already have two new conventions that sites can't possibly detect as alternatives to the normal foo+bar@dom.ain.

The standard (as in most common setup) for djb's qmail, was to accept/forward mail for <prefix>@user.example.com to user@example.com, as in: debian-list@e12e.example.com rather than debian-list+e12e@example.com.

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.

That is fair, but maybe the providers just want to stop account spamming on their sites, can you blame them for that?

Depending on your email provider, there are a ton of different ways to create brand new email addresses. Blocking off the single pattern of foo+bar@example.com just punishes legitimate users without causing any problem for spammers. Besides the fact that foo+bar@example.com may in fact be a legitimate unique email address, there's also just the case of people who routinely use username+sitename@example.com when signing up for anything as a way of tracking where incoming email is coming from.

I recently started adding random emojis and lyrics to gmail addresses, it isn't usually shown so it's a nearly-steganographic rick-roll.

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.

None of that is really a red flag for me. The biggest red flag is when I make an account and they send me my username and password in plaintext in the confirmation email. Makes me cringe every time.

Doesn't work on IE - depends on a business.

I made a saas tool for mac developers. Fixing all the quirks would cost far more than the potential 2% users are worth to me.

Slideshows - you mean even embeded Slideshare ones? Why? It's a good tool to explain certain ideas, and easily shareable one. We had our slides embeded on a TC post, and we used them as a significant source of traffic.

>I made a saas tool for mac developers.

There was once a time where this was a workable excuse, but today's browsers are actually pretty good about following standards. If you're doing something that works in some browser, but not all, then you're likely exploiting some weird quirk of that browser.

And of course, not testing if it works in x browser is different than actively stopping your webapp from running if it doesn't detect the right browser/os combination.

I'd say especially embedded slideshare ones. Just link to the PDF, or I won't read your content (and my browser will probably block it anyway).

I don't know what your product is, but I use four different browsers on a daily basis across three operating systems (it would have been six across 2 if not for the win10 privacy debacle, and even more if I had an android), and I want all my SAAS to work on all of them.

Experience says when they don't work everywhere, IT just dumps the service for another SAAS provider and everyone cheers.

Don't blame me for some of those things, blame my clients. I can only suggest so many times that something is bad practice, without getting fired.

Ah yes, I should have also mentioned clients. Can't win 'em all, huh?

Nothing drives me crazier than random restrictions on my password. I get that there's probably justifiable reasons to limit the number of characters, but if it's a character found on a standard keyboard, it should be available.

You think it's a cost thing ie what the server can compute....?

I forget the term I did this with openssl, Apache, I think with a cheap vps I get between 9 and 10 cost, bcrypt. Sorry if these are not directly related for hashing.

A few sites I have to use for my dishwashing job work ie. share point and a card company that manages my money, as well as another by WalMart, they don't allow special characters only upper case-lower case and digits. You'd think okay length then but some have limits like a 15char limit.

Wait. Why is zero restrictions on passwords a bad thing?

there should be a minimum length.

Or people will use 2-4 character passwords (often the initials of their name etc)

This is their problem then.

So fb and Twitter are either built by incompetent devs or they have too high a mgmt interference? (Since they auto play videos)

> So fb and Twitter are either built by incompetent devs or they have too high a mgmt interference? (Since they auto play videos)

That seems like it's asked with the expectation that the obvious answer is "no", but I believe it's "yes". Well, I have no idea of the quality of their devs, but someone in the decision chain thought that auto-playing videos was a good idea, and he, she, or they were wrong.

I agree with all your points except slideshows. Why so much hate against slideshows ?

I don't have a problem with slideshows, but a reason is that, in the UX perspective, elements that animate recurringly with previously hidden content (and possibly links) is confusing and not actually used, and then when you find something you want to check you have to use the slideshow pagination, which is cumbersome. Better to properly display the points of interest.

They are used by people who need to turn what should be 3 bullet points into a slow "presentation".

I don't like them because they make it difficult to copy and paste the whole of the content.

I was talking to one of the Facebook cofounders years ago, and he put it better than I could (he wasn't talking about slideshows specifically). I don't have an exact quote but it went something like this:

We don't optimize for impressions per session. Instead we optimize for the number of things a user does in a fixed amount of time, (or per session). The former is a poor proxy for the latter, and you can increase impressions by adding useless click through pages that ultimately drive away users and destroy your business in the long term. (In the short term, these things make your metrics look good.)

I bring this up because slideshows are a great way to artificially boost impressions.

> Doesn't work with Internet Explorer

Some of us just can't be bothered. My web app is tested on Chrome, Firefox, and Edge. If you want to use IE you are on your own and I won't support you unless you give me a million dollars.

You don't have to support all browsers, but but generally knowing what doesn't work on IE and avoiding the big problems these days is pretty easy.

How about case insensitive passwords? That one always bugs me because it suggests that maybe they are storing the password.

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.

Sure, it's possible to do it that way. But if I were taking bets, I know where I'd put my money.

That's a good point. I'm pretty sure my bank is storing the password because they also limit it to some (small) number of characters. I'm guessing it's because the web interface is just passing it on to some ancient back-end system.

> I'm pretty sure my bank is storing the password because they also limit it to some (small) number of characters.

I love how it's always the banks with these ridiculous password practices. I'm really glad that it's not some site where the password is protecting important information.

That reduces password entropy and makes the hashes easier to crack.

I didn't say it's a good idea, it's awful, just pointing it out though.

Well, does it? Even if you crack it you don't have the correct casing. So you don't have the original password. Of course doesn't help if every other website converts to lower case too.

But if you use bcrypt you can partially compensate by using a higher work factor.

> Well, does it? Even if you crack it you don't have the correct casing.

The 'correct casing' is any member of the set of all permutations of cases. So you both do, don't, and do not care.

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.

facebook logins work this way (sort of). they account for flipped case (caps lock on) and for passwords that accidentally have the first letter capitalized.

I knew I was forgetting something!

Case insensitive passwords is entirely a business decision. Banking websites in particular have huge numbers of non tech savvy customers. When they forget their password or type it in incorrectly, they don't go to the password reset form, they call into customer support. This costs an enormous amount of money.

Banks figured the cost of reimbursing people if their account is compromised is lower than the cost of having to field all of those phone calls.

Source: Used to work at a bank.

Yeah, that makes sense.

Once after my account was stolen from, I did a careful look at the website and sent in a list of questions and complaints about their practices. After enough bugging, a person eventually called me. The bottom line was essentially that I shouldn't be concerned because I'm not responsible for fraudulent withdrawals. It wasn't very satisfying.

The thieves got away with around $2400.

Why do you think that "Passwords have no requirements" is a sign of incompetence?

Length seems like a reasonable requirement, e.g. it can't be "asd"

Or "" ...

I'm pretty thankful on some websites when there are no password requirements. Like the article states, sometimes I am not coming back to that website. In truth the real annoyance for me is requiring an account. I wish more companies would just let me order without storing account details.

That sums up every govt and banking site in India.

Reply on news.ycombinator.com