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)
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).
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.
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.
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
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
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.
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.
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).
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
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.
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.
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.
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.
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]
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.
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.
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.
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 :)
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.
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.
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.
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"
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.)
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.
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.
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.
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.
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.
> 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.
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 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.
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.
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.
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.
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.
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.
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.
> 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 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.
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.
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.
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.
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.
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'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.
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.
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'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.
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