How Do You Know If A Web Site Is Secure?

How Do You Know If A Web Site Is Secure?

With all the hacking of web sites going on, just how safe is your information. Shamus offers some tips how how to determine just how secure a web site might be with your information.

Read Full Article

I registered with the Escapist to see how it did! - it seems to have pretty much passed the test. Didn't blink at the 35-character password. Email verification for password reset. Etc. etc. However, it did generate a (one-time?) URL which included my username (although just the username - it didn't show my email address or anything) which may not be absolute best-of-show security practice.

Don't encourage sites to be even more of a pain just to be able to post on a damn forum!

Great article as usual, Shamus. An interesting point on password length over gibberish is breaking the 14 character password mark.

The difference in "crackability" of a 14 character password and a 15 character password is in years of processing time and that's only if they don't use the traditional algorithms and brute force measures.

This is because passwords that are 14 characters or smaller are all stored in a hash and broken up into two 7-character parts (easy to crack a 7 character password) but if it's 15 characters or larger then windows does not store the LanMan hash correctly so both segments will be incorrect or null passwords to any decryption utilities trying to crack the LM. That basically ruins brute force attacks.

You do want to have at least a little curve ball in the 15 characters, but just a little dab will do it.

http://www.symantec.com/connect/articles/ten-windows-password-myths (myth #3 is the one quoted below)

Interesting side fact, a network admin could always set the environment to not store LM passwords at all, effectively side stepping the problem altogether. I would not be surprised if this eventually becomes the default as backwards compatibility becomes less of a concern with software being older than a decade.

But aren't passwords written in real words like your second example easily crackable by using rainbow tables? Between a 15 character gibberish password and a 15 character password written with existing words, it's still safer to use the gibberish one.

Subbies:
But aren't passwords written in real words like your second example easily crackable by using rainbow tables? Between a 15 character gibberish password and a 15 character password written with existing words, it's still safer to use the gibberish one.

I think his thrust is (and I could be wrong), a longer password consisting of semi-random words is something you can get users to generate more often than a gibberish password, so a single failure doesn't expose all of their accounts.

We're past the point that it's easier for machines to crack a password than it is for a user to remember it ... and so users re-use passwords across time and space, when they could be isolating their p-words in some fashion.

You're right, a purely random string of gibberish is always going to be stronger than words.

JustAnotherAardvark:

Subbies:
But aren't passwords written in real words like your second example easily crackable by using rainbow tables? Between a 15 character gibberish password and a 15 character password written with existing words, it's still safer to use the gibberish one.

I think his thrust is (and I could be wrong), a longer password consisting of semi-random words is something you can get users to generate more often than a gibberish password, so a single failure doesn't expose all of their accounts.

We're past the point that it's easier for machines to crack a password than it is for a user to remember it ... and so users re-use passwords across time and space, when they could be isolating their p-words in some fashion.

You're right, a purely random string of gibberish is always going to be stronger than semi or non-random words.

This is true in the case of entropy of the password. However more recent ways of attacking passwords (such as the aforementioned rainbow tables) are helped by the fact that the user is using real words in his password. This would make gibberish passwords more powerful than real word one. However I'm unsure of how long a password would have to be to actualy benefit from being gibberish rather than existing words.

In any case the best solution is to use a password manager that would generates random passwords of very high entropy rather than creating your own.

Lightknight:
snip

LM hash has been turned off by default since Vista's release. There may be some legacy systems that still use it, but for most services the difference between 14 and 15 characters is no longer as significant.

Also, not that all of the advice in that link is no longer relevant, but it was last updated in 2002. Password security has certainly gotten more issues since then.

Zombie_Fish:

Lightknight:
snip

LM hash has been turned off by default since Vista's release. There may be some legacy systems that still use it, but for most services the difference between 14 and 15 characters is no longer as significant.

Also, not that all of the advice in that link is no longer relevant, but it was last updated in 2002. Password security has certainly gotten more issues since then.

Saved me some Google Fu. As a CompTIA A+/Net+ and Microsoft Certified IT professional I read that comment and was actually scratching my head trying to remember when LM was last actually in use. I almost want to say it hasn't been seriously been used since the Win 9x days.

On to the reason I came to the thread, on the point of security questions (mandatory or otherwise) one of the best tips I have ever found was to provide answers which could not be researched on facebook since most of the companies using them don't seem to "get" how weak those questions make their security measures when answered honestly. So when they ask your mother's maiden name you say something like purple instead of Smith, and so on....

Ken Sapp:
Saved me some Google Fu. As a CompTIA A+/Net+ and Microsoft Certified IT professional I read that comment and was actually scratching my head trying to remember when LM was last actually in use. I almost want to say it hasn't been seriously been used since the Win 9x days.

95/98 definitely had alternative storage methods available, as (potentially) did NT. This is a combination of what I can remember from my Systems Security course last semester and Wikipedia's article on the LM hash.

On to the reason I came to the thread, on the point of security questions (mandatory or otherwise) one of the best tips I have ever found was to provide answers which could not be researched on facebook since most of the companies using them don't seem to "get" how weak those questions make their security measures when answered honestly. So when they ask your mother's maiden name you say something like purple instead of Smith, and so on....

One of my favourite news stories ever was when Sarah Palin's email address was hacked, because all of the security answers were on Wikipedia.

A note: consider security questions to be additional passwords. Do not use them like normal people (with actual answers), salt the earth and put ridiculous shit in them that only you would consider to be the answer to such a question, or if this is a security question recovery that doesn't involve embarrassing yourself by talking to somebody on the phone, even things that cannot be pronounced by human tongues. Just make sure you have some reasonably secure way of remembering them.

The problem is that these factors don't actually determine how secure a website is, they determine how secure the website thinks it is. The most important vulnerability in account driven websites is how the data at rest is stored and secured. Admittedly this isn't stuff you can/should test yourself but it's far more important than how secure your password is.

For example; your password being fully CORRECT HORSE BATTERY STAPLE'd up is of absolutely no use to you if they don't properly encrypt the passwords at rest since an attacker that gets hold of the database can just read them out. In addition if the hashing algorithm is found or derived then it's child's play to reverse the hashing, strip the salt and get the password that way.

That's before we even get into badly validated input or cross-site trickery. None of that encryption means jack if an attacker can overwrite the email field for a record, request a reset and just reset it themselves.

Subbies:
But aren't passwords written in real words like your second example easily crackable by using rainbow tables?

No. To start with, salting eliminates any possible use of rainbow tables (see here). Rainbow tables also only work well for relatively short passwords, or those of known length. It's not feasible to produce tables covering passwords of unknown arbitrary length.

Between a 15 character gibberish password and a 15 character password written with existing words, it's still safer to use the gibberish one.

Why use a 15 character password? The entire reason for having short passwords is that long strings of gibberish are essentially impossible for people to remember (or that websites don't allocate enough space to password storage, but there's really no excuse for that these days). But we're really good at remembering long strings of meaningful words; just think how many songs you can remember the words to, for example. A 15 word password can be easy to remember, while being just as difficult to break by a dictionary attack as a 15 character one is by a normal brute force attack, and of course far more resistant to said brute force attack.

That said, even a 15 character password made from existing words is not necessarily any less secure. The important thing about all shortcuts to password breaking is that they rely on assumptions about what form a password will take. If an attacker doesn't expect to see passwords made up of combinations of random words, they're not going to bother with an attack that would be better at breaking that kind of password but that doesn't help at all for more common passwords. Given what the most common passwords actually are, no attacker is going to worry about elaborate methods of breaking long passwords when they can get at the majority by just typing "password" and "123456" by hand.

A good password is ultimately one about which an attacker has no prior knowledge on which to base their attacks. If they know your password is 8 characters long and contains at least one upper case letter and one number, they can tailor their attack to that specific type of password. But if all they know is that your password is somewhere between 1 and 127 characters, where exactly do they start? Passwords of 15 characters made up of words is only a tiny portion of all the possibilities. The attacker also needs to check if it's actually 14 characters, or 16, or 120, and they need to check if it's made of real words, contains various substitutions, is made up of gibberish, is just "password" repeated over and over again, and so on. A 15 character password made up of words is only less secure than one made up of random gibberish if an attacker can reliably know which of the two they are dealing with.

Subbies:
In any case the best solution is to use a password manager that would generates random passwords of very high entropy rather than creating your own.

Not necessarily. A high entropy password of random gibberish generated by a password manager is no better than a high entropy one generated by a person stringing words together. Password managers are a great solution to the problem of needing to remember multiple passwords, but the method by which you generate the passwords for it to store is entirely irrelevant.

Of course, there's also a good argument to be made that password strength is irrelevant. Good security practice on the part of a website makes actual password choice a factor in only a tiny proportion of attacks. Depending on the level of security and how an attack plays out, the actual password can be either easily available in plaintext or impossible to break at all; it's only rare attacks where the strength of a password actually becomes factor. From that article:

"Demanding passwords that will withstand offline attack is a defense-in-depth approach necessary only when a site has failed both to protect the password file, and to detect the leak and respond suitably"

In other words, strong passwords are only necessary if the sites you're using them on are incompetent.

Zombie_Fish:

Lightknight:
snip

LM hash has been turned off by default since Vista's release. There may be some legacy systems that still use it, but for most services the difference between 14 and 15 characters is no longer as significant.

Hmm, I admit that the person who taught me network security has been around in the industry for several decades so his information could be old but his information has been golden for me in most areas. He seemed to think the difference was years of decryption time. Is it possible that the additional values start to reach a critical mass at that point where the permutations hit exponential highs there?

On the other hand, I do clearly remember the professor drawing two squares on the whiteboard for the two hash values so I'm not exactly hopeful that he was up to date now. Do you happen to have a link to this claim? I would appreciate being able to read it.

Also, not that all of the advice in that link is no longer relevant, but it was last updated in 2002. Password security has certainly gotten more issues since then.

It was last updated on November 3rd 2010.

Lightknight:
Hmm, I admit that the person who taught me network security has been around in the industry for several decades so his information could be old but his information has been golden for me in most areas. He seemed to think the difference was years of decryption time. Is it possible that the additional values start to reach a critical mass at that point where the permutations hit exponential highs there?

On the other hand, I do clearly remember the professor drawing two squares on the whiteboard for the two hash values so I'm not exactly hopeful that he was up to date now. Do you happen to have a link to this claim? I would appreciate being able to read it.

The point about it being disabled is just on Wikipedia: https://en.wikipedia.org/wiki/LM_hash

The claim about the difference being no longer as significant is based on the fact that the hash function now used is based on MD4. Current attacks on MD4 are not dependent on the length of the password, and the best pre-image attack runs in 2102 operations.[1]

It is worth noting however that the fact that it uses MD4 is not a good thing. The hash function was rendered obsolete four years ago.[2]

It was last updated on November 3rd 2010.

Yeah, I'm not sure about that. The post itself says that it was last updated on 7th March 2002.

EDIT: And even then, 4-5 years is a long time in the security world. In that time Heartbleed was both introduced into OpenSSL and patched after the amount of furore it caused following its discovery. One of my favourite video creators did a video on password storage, where he preceded it with 'By the time you watch this video the advice will have changed.'[3]

Speaking as a web developer/forensic graduate a longer password does not necessarily mean a more secure password in any way. Symbols will improve a passwords strength massively, especially things such as a pound sign as a lot cracking software won't even consider to try it. Variety is key which is why a lot of sites force 1 Upper, 1 Lower and 1 number as minimum now a days.

Also no one with database access should ever be able to retrieve a users password that's what password reset tools are for, any sort of login information or password should always be encrypted with one way encryption (Salted).

As for forgotten password tools, an email with a link which goes to a reset page is far better than a secret question especially if the link is set to only be valid for 30mins or so.

Shamus Young:
If a site limits you to 8 or 12 characters, then it might mean they're not doing this.

Wouldn't matter if they used hashes or not at that point. Chances are all 8 to 12 viable character passwords are already in rainbow tables. It's a simple reverse lookup at that point.

Sad to see a list of things that should flag a site as unsecure, but not any of the few things that flag it as secure.

First assume all sites are already compromised by your worst enemy. If you hate North Korea assume they already have your password, and a list of the sites it goes to. Keep intel on sites that only use a password down to a minimum.

Second, any site that doesn't use two factor authentication is already rooted, and just pooring your information to organized crime.

Third, have your backup two factor authentication passwords locked in a vault and ready to use. The moment your phone goes missing be prepared to buy a new phone, remote wipe the old one, and link a new two factor key to your accounts that allow it.

Finally, let all the other suckers keep their poor security measures. As long as their is a target rich environment of easy prey you're safer, but not safe. Wolves cull the weakest first, and Penguins push the weakest into the sea lion infested waters to see if there is any danger.

I don't mind mandatory use of some numbers and shift characters, but in combination with a limit on passlength that's a pain in the ass and you're forced to type gibberish to get anything resembling a decent password.

Worse still is I encounter sites that are not case sensitive even today! With tight limits on length (like 16 fe) and with minimum and maximum character counts.

Internet security vs hacking is a constant arms-race.

As soon as a website is reachable through the internet it becomes a target, a risk. You never know whether you're safe, or some hacker's been riddling your site with secret backdoors for months.

As soon as it's on the internet, I consider it open and public regardless of all the privacy options I've set, regardless of a million capitals, digits and punctuation in my password, regardless of how many certificates the site uses.
All it takes is one human error somewhere and everything is at risk (The heartbleed bug, anyone?)

Ofcourse I do use online banking and dropbox and all that stuff. I just don't expect it to be private or secure.

Umm... most of you are talking jibberjabber to me.

What I will contribute to the whole matter is that I think the security questions are flawed. I like it when I get to create the question. I already use other stuff to answer them, but it would be better if I got to create the question too.

Square Enix is terrible in this regard. I've had to keep resetting my FFXIV: ARR password because I played at a different household. Same system, different household. Every damn time. I can't keep up with what I've made it at this point.

Just had to change my password for a site I don't use especially often and I had forgotten that the site broke pretty much every recommendation except that its character range was 8-20 rather than 8-12. It's good to know that the government is at the forefront of internet security. -_-

Another thing I dislike about length limits on passwords is that just because the limit is enforced on one of the password forms doesn't mean that it is enforced on all of them.

I once reset my password on a website, and it turned out that the password entry had a character limit on it and as a result cut off part of my password. Yet the password entry on the login screen didn't have a limit, and thus submitted my full password.

I only figured this out when my account was locked out for so many incorrect logins and I said that I forgot my password. After that, they emailed me my password in plain text (-_-') and I noticed what was up then.

Lightknight:
The difference in "crackability" of a 14 character password and a 15 character password is in years of processing time and that's only if they don't use the traditional algorithms and brute force measures.

This is because passwords that are 14 characters or smaller are all stored in a hash and broken up into two 7-character parts (easy to crack a 7 character password) but if it's 15 characters or larger then windows does not store the LanMan hash correctly so both segments will be incorrect or null passwords to any decryption utilities trying to crack the LM. That basically ruins brute force attacks.

Umm, ignoring the out-of-date-nesss of the advice/article, I'd also want to point out that if any website is using Windows of all things to secure the passwords...well, how should I put it - that must me another entry in Shamus' list.

In addition any advice for "oh, here is how to go around an insecure hashing algorithm" is wrong. Saying "use 15 characters" instead of "FUCKING STAY AWAY FROM IT!" can be called "misleading", if we have to be short, and "actively harmful and counter-productive" for practical purposes.

P-89 Scorpion:
Don't encourage sites to be even more of a pain just to be able to post on a damn forum!

Encourage how exactly? If anything, Shamus advocates making it easier by removing the nonsensical "security" restrictions. Even then, that's not new take on it, anyway - anybody dealing with security and is at least half-decent has been advocating the same points for years now. Shamus us bringing these points to the wider public - a good thing if we are to abolish these "security" practices.

Which exact point makes it harder to use websites?

Subbies:
But aren't passwords written in real words like your second example easily crackable by using rainbow tables?

No, rainbow tables only help with straight hashing - pretty much anybody uses salted hashes. To say these are extremely hard to defeat with a rainbow table is an understatement. An attacker needs both the hashing algorithm AND the hash to generate the table. And since every user has their own hash, then they can't feasibly do it. Even if they were to somehow gain the hashes, they would still need to generate one table per hashed password. Thus, they would need to attack each user seperately which is way more resource intensive than an attacker usually wants to deal with.

Sure, if the attacker targets you specifically (or any other single person) then you (or they) might be at risk. Still, if that's the case, chances are the attacker would most likely go for other attack vectors rather than blow so much CPU power (as well as all the other time and effort needed) to just attack a single password.

ForumSafari:
The problem is that these factors don't actually determine how secure a website is, they determine how secure the website thinks it is. The most important vulnerability in account driven websites is how the data at rest is stored and secured. Admittedly this isn't stuff you can/should test yourself but it's far more important than how secure your password is.

For example; your password being fully CORRECT HORSE BATTERY STAPLE'd up is of absolutely no use to you if they don't properly encrypt the passwords at rest since an attacker that gets hold of the database can just read them out. In addition if the hashing algorithm is found or derived then it's child's play to reverse the hashing, strip the salt and get the password that way.

That's before we even get into badly validated input or cross-site trickery. None of that encryption means jack if an attacker can overwrite the email field for a record, request a reset and just reset it themselves.

At my university, we had some overly draconian password policies - they had to be really long and not contain anything that would "aid" in brute forcing it - in addition to capitalisations, special characters and length, you couldn't have sequences (123password or abcpassword), nor any word, for that matter. And whoever developed the fucking password validator decided to include all sorts of dictionaries - English, French, Italian, Welsh, Polish just to name a few. I don't even know how many they were, as when trying to create a password, you just get "entered text contains a word in [some language]" - these are just the ones I've hit. And for many of them, I never found out what the word was - seemed that any time I tried anything with a vowel in it, I'd hit a word in some language or other, so, in the end, the password had to me a long line of gibberish which is really hard to remember. And since you just wasted, like, 15-20 minutes entering various passwords, few moments later the gibberish would have evaporated from your head.

Setting aside that making the users unable to remember the passwords does not help with security, and that the restrictions actually made the attacks easier (reduced search space), we found another issue with it. Email only used 8 characters. Ever. Even if your password was 20 characters long, if you were logging into your university email box it truncated the input to 8 and everything 9+ was ignored. And you were logged in, if those first 8 characters are were correct.

On a separate note, related to websites and security - the user security is one part of security. There are various other attacks that don't rely on the users' actions (e.g., password selection). I'll just use uni again for an example. Or rather, just my time in uni - one relatively well known pizza place came to the town. And they offer ordering over the internet. In the same week compsci students realised that the website was a joke from security standpoint - all the data for the order was stored client-side. ALL OF IT. Including the price. So anybody could easily order any amount of pizza for a pound. Or whatever price they wanted, really. It got patched eventually but it still took a couple of weeks.

Even though it's not to do with with compromising other accounts, it's just a real-world example of how an attacker doesn't necessarily need to attack other accounts. Exploiting SQL Injection vulnerabilities can bypass even the strongest password, while various bugs can remove the need to login as a specific user at all.

I think the only program that ever encouraged me to make a password without those stupid upper/lower/symbol/number rules was Guild Wars 2 where they explained the benefits of just using four words you could remember in a sequence. Funnily enough, I still remember that password to this day despite the fact that I haven't written it down anywhere or even played Guild Wars 2 in several months.

DoPo:

On a separate note, related to websites and security - the user security is one part of security. There are various other attacks that don't rely on the users' actions (e.g., password selection). I'll just use uni again for an example. Or rather, just my time in uni - one relatively well known pizza place came to the town. And they offer ordering over the internet. In the same week compsci students realised that the website was a joke from security standpoint - all the data for the order was stored client-side. ALL OF IT. Including the price. So anybody could easily order any amount of pizza for a pound. Or whatever price they wanted, really. It got patched eventually but it still took a couple of weeks.

Even though it's not to do with with compromising other accounts, it's just a real-world example of how an attacker doesn't necessarily need to attack other accounts. Exploiting SQL Injection vulnerabilities can bypass even the strongest password, while various bugs can remove the need to login as a specific user at all.

That's just fantastic. I've seen some pretty majestic fuck ups, like the one you mentioned where a user account is logged in via a client side token and a simple URL edit can take you anywhere because you're logged in, but I've never seen financial data client side.

This is my profession too, I took computing at university and work as a sysadmin, so it's a little galling when people think complex passwords = security. Realistically as long as your password is good enough to prevent:

1. Some random shitlord guessing it whilst you're afk
2. you being in the first ~25% of cracked passwords

then a better password is doing jack all. Most vulnerabilities are security cock ups from the storing of data, proper account encapsulation or service deployment. Things like not properly assigning account rights to the database (our old friend 'GRANT ALL ON *' strikes again), providing cookies that can be easily rewritten or that contain easily read data, not validating input (that still happens in 2015), not encrypting files and, surprisingly common, not preventing users from backtracking up the server's filesystem to files they shouldn't have access to because the admin doesn't understand how to properly secure their web service.

Heck, as you rightly say a complex password is only going to make it harder to remember and the best password in the world is defeated when the user feels the need to right it down on the device.

EDIT: The other biggies are not patching servers in a timely manner, not changing default passwords and not preventing things like root login.

I'd also want to point out that if any website is using Windows of all things to secure the passwords...well, how should I put it - that must me another entry in Shamus' list.

I'm not sure I agree with this though, in my experience Windows services don't seem to have a significantly different attack surface to Linux/BSD services. Heck, IIS seems to be good against, and susceptible to, the same monkey business that Apache is. Windows is easy to get running compared to Linux for newbs so you see a lot of badly configured Windows stuff but I think in the hands of a professional it's probably about as secure to malicious attacks.

ForumSafari:

I'd also want to point out that if any website is using Windows of all things to secure the passwords...well, how should I put it - that must me another entry in Shamus' list.

I'm not sure I agree with this though, in my experience Windows services don't seem to have a significantly different attack surface to Linux/BSD services. Heck, IIS seems to be good against, and susceptible to, the same monkey business that Apache is. Windows is easy to get running compared to Linux for newbs so you see a lot of badly configured Windows stuff but I think in the hands of a professional it's probably about as secure to malicious attacks.

I didn't mean Windows as in a Windows based application, but Windows as in the OS itself.

 

Reply to Thread

Log in or Register to Comment
Have an account? Login below:
With Facebook:Login With Facebook
or
Username:  
Password:  
  
Not registered? To sign up for an account with The Escapist:
Register With Facebook
Register With Facebook
or
Register for a free account here