Go Back   Computer Forums > General Computing > Cyber Safety and Computer Security
Click Here to Login
Join Computer forums Today

Thread Tools Search this Thread Display Modes
Old 03-06-2014, 08:49 AM   #1
Solid State Member
Join Date: May 2012
Location: United States
Posts: 7
Default How passwords without punctuation hurt security

I hate it when banks do not allow punctuation marks in passwords. Can someone give me the number of how much more insecure a password is that does not allow punctuation in it is? I know each character that is added adds 2^x but not sure what that number is. Just wondering.

brianstoiber is offline   Reply With Quote
Old 03-06-2014, 09:59 PM   #2
Site Team
celegorm's Avatar
Join Date: Sep 2006
Posts: 10,720
Send a message via AIM to celegorm
Default Re: How passwords without punctuation hurt security

they don't do it because it's more of a secure password, they do it because it is more secure for their system. special characters and punctuation can reek havoc on SQL if the input isn't sanitized properly. Do a google search for SQL injection and you'll see what I mean.

"as a fanboy i refuse to admit it and will pull countless things out of my butt to disprove it"

Team Thelegorm! Total Kills: 21 (i iz in uor profile, editsing your sigz)
celegorm is offline   Reply With Quote
Old 03-07-2014, 04:40 AM   #3
In Runtime
Join Date: Feb 2013
Location: UK
Posts: 156
Default Re: How passwords without punctuation hurt security

Ok there are a couple of things which need to be addressed here:

1) As Celegorm said, punctuation and special characters can cause havoc on back-end systems (SQL being the most common, but by no means the only one). These vulnerabilities in this instance come from any free-form text entry box on the internet (such as this one!) - however, more generally they arise from any mechanism where a user is able to send custom content back to the server. The solution in this regard is to ensure that all user-supplied content is sanitised/parsed as benign text and not interpreted as commands.

That said, this (nor anything else) is a valid reason for not allowing any character to be used in a password field (usernames and stored content is different). A secure password policy should:
a) allow any character to be used
b) impose a minimum length restriction of 12 characters (ideally more, absolutely never lower than 8 - it's pointless even having a password at this length)
c) not impose a maximum password length (this is a definitive indicator that d) is not being done!)
d) use salted hashes on all passwords on the client machine so that the password is never transmitted over the network (including HTTPS)
e) preferably use a secure hashing algorithm such as SHA-256, but failing that anything except MD5
f) separate the username/salt database from the password hash database
g) encrypt the password hashes database with 256bit symmetric-key cryptography (such as AES256) to prevent offline attacks on the hashes in the event both the username/salt database and the password hash database get stolen (it happens all the time!)

If a website ever emails you your password then they have definitely violated c), d), e) and f) above - and likely g) too. Password recovery should be done via a reset-password feature with multi-factor authentication that you are the account owner (e.g. SMS, email etc.)

Additionally, if a website ever imposes a maximum password length then they are definitely violating d), e) and f) above - again probably g) too. This is assured because a hashing algorithm, such as SHA-256, will always return a 256-bit (32-bytes) block of alphanumeric characters. Therefore the buffer that is receiving this data on the server only ever needs to be 32-byte big. A fixed maximum of 16 (for example) almost certainly means that there is a 16-byte character buffer on the server which, if not bounds-checked, is vulnerable to buffer overflow (much more dangerous than SQL injection) which can lead to the entire server being taken over by an attacker.

2) As for the OP question about the actual maths behind the subject, take a look at the 'Random Passwords' section of wikipedia page: https://en.wikipedia.org/wiki/Password_strength which essentially says that the 'x' in your question relates to the number of bits of entropy the password has. This is a function of the key-space (number of possible characters accepted by the website, hence step a) above is vitally important) as well as the actual number of characters used by the user.

In simplified terms, this can be easily understood by saying 'guess a 4 digit pin' vs. 'guess a 4 character password' - even if the latter is restricted to only lower case, there are still 26 options for each symbol rather than 10 - so you're likely to guess/crack the pin number much faster.

One final point on this which I can't stress the important of enough is this:
It does not matter how many character sets (e.g. digits, special, upper, lower) your password makes use of - only how many the website allows.
For every extra character set, an additional lump of entropy is available to the users which makes any attempt to break the passwords vastly more difficult and time consuming.

If the website enforces you to use a subset of these then this immediately gives attackers information - in short, make the number of accepted passwords as large possible and don't allow dictionary words which occur in all rainbow tables (this dictionary word check is an additional step which I forgot to include in the original list, but is an exceptional security mechanism).

I hope this has helped you understand password security concepts better, and that you try to educate others along similar lines. If it wasn't already obvious, this is a particular irritant of mine with online services using poor password policy.

Happy surfing!
_michaelm is offline   Reply With Quote

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off

All times are GMT -5. The time now is 11:50 PM.

Powered by vBulletin® Version 3.8.8 Beta 4
Copyright ©2000 - 2019, vBulletin Solutions, Inc.
Search Engine Friendly URLs by vBSEO 3.6.0