Is there a reason why certain sites don't allow periods in passwords?

views:

3259

answers:

+17 Q:

Is there a reason why certain sites don't allow periods in passwords?

I was just wondering why certain website don't allow anything other than letter and numbers in the password field.

Is there a security reason or perhaps it's just a limitation of the DB they are using? Thanks for the info.

Edit: It appears that Oracle's database doesn't acknowledge uppercase and lowercase? Is this true? I was told that via PM. Thanks for the information guys, this is really useful stuff.

I wonder why this question has 3 votes to close though. Not enough jQuery and freehand circles?

Isn't it to avoid all possible SQL injection?

GôTô 2010-10-18 14:00:05

@Goto, how would `.` be in danger of allowing SQL injection? `--` , `;`, `'`, and SQL keywords would be more dangerous.

Brad 2010-10-18 14:01:01

I doubt it';DROP TABLE Users;--

David 2010-10-18 14:01:54

@Goto: Why would a '.' enable SQL injection?

Serg 2010-10-18 14:02:46

@Brad: I'm no expert and don't know how you could perform SQL injection other than by using a `'`, but I'm sure it is not the only way. Plus the question is about other characters than letter and numbers.

GôTô 2010-10-18 14:03:53

@GoTo, for some reason I thought the OP was about `.` only in the username.

Brad 2010-10-18 14:16:36

They probably think it's safer that way, but restricting characters in the input field is not the right way to solve SQL injection. See http://bobby-tables.com/

Andy Lester 2010-10-18 14:30:21

Possibly, but disallowing certain characters in usernames then is a sign that the developer is either lazy or doesn't know how to prevent such attacks properly.

Cthulhu 2010-10-18 14:31:03

@Cthulhu: indeed, and that's a pain, considering my username has two accents!

GôTô 2010-10-18 14:38:50

+17 A:

They're brain-dead and scared of punctuation in general - and dot counts as punctuation. It is more a case of 'friendly-fire' than dot being dangerous. Dash is pretty harmless too.

One of the concerns is SQL Injection, of course. The other is competency of programming workforce.

Jonathan Leffler 2010-10-18 14:00:44

In previous jobs where our own systems had requirements like this (for example, I once worked at a bank that allowed ONLY letters and numbers in users' passwords), it was often a matter of "that's what the 3rd party system/widget/solution we bought requires." So sometimes the "competency" issue goes back to whoever decided to buy it (usually not programmers) and whoever they bought it from.

David 2010-10-18 14:04:46

Chase is one of those companies. It boggles the mind how a site like Stack Overflow allows me to configure a more secure password than my *banking* site. *sigh*

Nimmy Lebby 2010-10-18 21:51:11

If punctuation in the password becomes an SQL injection concern, **they're doing it wrong.**

Roger Pate 2010-10-19 07:11:36

In general, it's a bad practice to just restrict passwords to numbers and letters. However, it does help to protect the code from "code injection" where a hacker passes some instructions as part of the password to gain access to the system. A password like `Apple;"Delete * from users;"' could end up doing damage if the developer didn't take proper care of escaping user input.

Another problem is the use of special characters that might cause conflicts in the code behind the site. Or special characters that depend on the specific character set/encoding that's used in the database. Letters like ë, è, ï, î and ì are all special characters that could be used, if allowed. But they sometimes end up being translated the wrong way.

Another problem is that some people tend to easily forget their password, which becomes a bit more complex to remember if you're allowed to use special characters. By restricting the password to fewer combinations, you also make passwords easier to remember.
Unfortunately, it also makes them easier to hack...

And often it's just a policy set by management of certain companies who just don't know better. The restriction could be just a management decision, with no logical explanation than management wanting passwords to be stored that way...

Workshop Alex 2010-10-18 14:06:58

So the gist of it is, sites request letter-number passwords because some developers might not have defenses set up in case of SQL injection attacks?

Serg 2010-10-18 14:09:31

Actually, more because they just fear injection attacks, even though the code itself might offer full protection against those. To make it worse, it doesn't have to be SQL code. It could be JavaScript code in the hope it gets executed on the server. Or PHP code. Or ASP code. Or ColdFusion code. Depends on the languages used to create the site and it's vulnerability to these kinds of attacks.

Workshop Alex 2010-10-18 14:18:45

JavaScript code executed on the server?

dreamlax 2010-10-18 20:53:39

@dreamlax, it's unlikely but it can happen! Even a server can execute javascript, once it's put in a proper context. However, the JavaScript can become part of a server-side page and then bounce back to the next client call, to be executed by the next person who visits the page.

Workshop Alex 2010-10-19 12:27:39

+7 A:

no reason at all, except for sloppy DB coding where they would allow plain text in the DB or use the (non-portable) DB functions to hash the password and use direct SQL statement. This seems just like plain string validation.

Other than that, on the pratical side, special character placement in foreign or cramped keyboard is tricky and might be more frustrating for the user that are traveling (or in more modern case alternative input like onscreen keyboard on smartphone). Some website might even push the system further by providing their own on-screen keyboard to log in ( with various scrambling ).

Disallowing special char helps QA, and reduced multi-platform user frustration.

And finally, Allowing a limited (deemed safe) character set (that is not only punctuation but also more language specific char in unicode), developper can also avoid encoding confusion between the browser and the server application (form data encoding is not very clear in the standard, and can be tricky on some browser).

dvhh 2010-10-18 14:08:48

Allowing special characters doesn't have to mean Requiring special characters. If the user knows that they will be logging in on a system that makes it hard to type these characters, the sensible solution is to not use those characters.

Graham 2010-10-18 15:46:34

In an ideal worlrd the user would know of course, but in some very general cases (95% of the case), would that be because the mobile site is added after, or the user didn't know about foreign keyboard layout before they travel for example.

dvhh 2010-10-18 23:22:43

Disallowing certain characters because *some* users *might* travel to sites that *might* not make typing them easy — and those users *might* not know how to work around that — would be strange.

Roger Pate 2010-10-20 12:56:45

Might induce some frustration, and the target of the website is not known, plus I mentioned the possibility of having a mobile website with more limited/frustrating input, or worst (videogame system).

dvhh 2010-10-20 13:14:29

I have never not been able to find the period on any keyboard.

klausbyskov 2010-10-20 15:30:22

humm, so you a telling me your password contains a period ;) , I already experienced different keyboard from different country, and for example I havea japanese version of a fujitsu u2010 where the back quote would be a combination like this "shift+fn+." http://pocketables.typepad.com/photos/uncategorized/2008/11/25/fujitsu_looxu_comp_kb.jpg (even worse usually the backslash is the yen symbol), even french keyboard got e accent cute which french wouldn't consider as much as special.

dvhh 2010-10-20 15:38:18

and french mac keyboard doesnt show braces/brackets http://www.whytraveltofrance.com/images/azertykeyboard.jpg

dvhh 2010-10-20 15:52:46

+8 A:

I worked at one place that wanted to be able to read passwords over the phone (that's how support was done). Support people didn't know all the names for symbols (hash, bang, pipe, ampersand/and, asterisk/star) and other issues (which left bracket do you mean, which quote, etc). So they didn't allow any punctuation.

Not a good reason (support shouldn't know my password), but you didn't ask for only good reasons :)

2010-10-18 14:31:17

This is a good reason, and a valid one to eliminate some symbols. Not just anyone in support should have your password, but when someone can access your billing details (CC number, billing address), modify your account, or has physical access to your machine (or a machine hosting your content/services), you've already trusted them with far more than what your account password protects. That said, most sites never need to do this, because interacting over the phone or in person is an extreme rarity.

Roger Pate 2010-10-19 07:06:22

(Should I mention you should never use the same password in multiple places?)

Roger Pate 2010-10-19 07:09:12

@Roger Pate: I use a good system where the center body of the password is the same, but the extremities are different according to the website. Works very well and doubt anybody would notice a pattern right away.

Serg 2010-10-20 11:48:32

@Sergio: That's common, but unless you know details about how the password is managed and stored for every site (and you don't), you can't trust it to protect other passwords. I'd not use it unless the conversion is clearly one-way, but usually that eliminates the benefit for most people of figuring out the password in their head. Instead, I use unique passwords and manage them in KeePass[X].

Roger Pate 2010-10-20 12:53:15

+1 A:

About upper/lower case: if you store the password in plain text, then that might be an issue. I'm not sure about Oracle, but SqlServer considers 'Password' and 'passWORD' to be identical.

If you store the password as hash, then the casing of the original is not a problem: the password acts case-sensitive.

Hans Kesting 2010-10-18 15:49:17

Thanks didn't know that.

Serg 2010-10-18 15:49:55

+1 A:

there is no possible reason. They are just incompetent. Any concerns about sql injection or anything else is just wrong. That just tells you that they are worried about a possible security injection because they aren't hashing or encrypting your password.

Darren Kopp 2010-10-18 16:16:02

There is other concerns than technical. See user479383 comment for an example. In general, you are making a general statement which needs proof, not just examples for cases that one might come up with.

egaga 2010-10-28 00:56:19

+1 A:

I guess the end users foolishness are also part of the problem. If they have a period in the password and store it somewhere, when they copy it the could get only a part of it (before the period). I am not quite sure about that,just an idea. But definitely SQL injection also have weight in this decision as making passwords more "readable". I mean "ajh.wer$ wer" does not looks like a password to me as "Yqw*123w$".

Yasen Zhelev 2010-10-18 16:16:33

ansaurus

tags:

views:

answers:

Is there a reason why certain sites don't allow periods in passwords?

related questions