Short passwords 'hopelessly inadequate', say boffins The availability of password-cracking tools based on increasingly powerful graphics processors means that even carefully chosen short passwords are liable to crack under a brute-force attack. A password of less than seven characters will soon be "hopelessly inadequate" even if it contains symbols as well as alphanumerical …
"They totally ignored her letter telling them the change of address because anybody could have written it."
Well, yes, you'd have been f***ing furious if they'd changed her address because some nefarious person had written to them. It used to be the most common way of defrauding an account back when I worked in a branch (yeeeaaars ago). Not to mention that relying on a letter sent (presumably) unregistered with no guarantee of delivery and assuming "job done" isn't the best technique for changing your address. I take heart in the fact that my bank (not Barclays) only lets me change my address in person or over the phone subject to the normal ID procedures.
Besides, I'm guessing the statement was about *online* security..
The Georgia Tech analysis makes sense only if the attacker has the hashed passwords. The threat to your password is keylogging, phishing, SQL injection etc. Online brute-forcing isn't very feasable against well protected sites.
Schneier's recent Cryptogram has a section about password policies at various sites:
http://www.schneier.com/blog/archives/2010/07/website_passwor_1.html
Policies at some well-known sites:
Amazon: 6 chars unrestricted
Fidelity Investments: 6 chars unrestricted
facebook: 6 chars unrestricted
Hotmail: 6 chars unrestricted
Yahoo: 6 chars unrestricted
Paypal: 8 chars unrestricted
The people who run real sites serving 100s of millions of users know that 6 chars is enough to protect against online attacks, and make sure that there's no offline attack. People who tell us that 12 chars are necessary have no idea what is actually going on.
My amazon password is 16 chars long. Maybe he's talking about minimum lengths and you didn't pick that up.
On the general side of things, what I do is:
Pick _one_simple password and use it for everything.... Err.
For everything non-critical, like El Reg logins, NY Times logins, etc...
Then I have a second level of multiple, harder, but often re-used passwords for things that I do care somewhat to protect.
Important things like my bank, computers and email get unique passwords. And, yes, Amazon does count as important as you can spend my money on it.
all those end in a password encryption app and I keep the file only on different USB keydrives, not on the harddrive, so that you don't have access to the password file unless I plug in the drive.
I didn't get logged in. Trusting large companies to keep secure up-to-date database software is like asking me to keep my computer up-to-date. Sure I try my hardest, but if some security vuln is found that I can't patch in time, then it may be possible for a remote attacker to access a list of usernames and hashed passwords (hopefully Amazon don't store my card details in the same table). In that case, they're likely to crack the first several thousand (most likely in about 3 hours) and then leave it at that. My username and password (which is also 16 characters) would be one of the last to be cracked and my security might be enough.
Just because they only ask for 6 or 8 characters doesn't mean that they know best, it just means that that's sufficient for the chance of a brute force attack to be reduced. This means that banks will cough up the money that I lose if amazon's servers are compromised. It's practical security, finding the optimum solution (read: profit maximising solution) between putting customers off with forgettable and therefore awkward passwords (meaning few sales) and security. 8 characters is a compromise; they have worked out the projected cost of a break-in and weighed it against the potential costs of prohibitive security policy. This doesn't make them masters of security, just good business.
> OK, tried it. It doesn't work
Well there's something strange going on then, because (I checked this before I posted and again just now) I CAN log into my amazon account (both .com and .co.uk) using BOTH my 14-letter password and just the first 8 characters of it. Only 7 characters fails.
I've found that if add incorrect characters after the 8th, it fails. But If I put the first 8, 9 or 10 in they all work.
I can add incorrect characters after the full one and it works.
Does this happen for anyone else but me, then?
The only way I can think that this would work is if they stored my password compared the start of it with the entered string, truncating the longer, or if they stored a hash for every length from 8 to 14. Both of which sound mad, but it's honestly working this way for me.
Your entry for Paypal, 8 chars, says you're wrong! Paypal may not think 12 chars is needed, but they obviously think that more than six is.
Anyway, many of those sites will not admit to intrusions even when they are aware of them, so your suggestion that "the people who run real sites know..." is spurious.
I suppose the people who run real banks know how to run, err, real banks? Experience of the past few years says they don't!
> Your entry for Paypal, 8 chars, says you're wrong! Paypal may not think 12 chars is needed, but they obviously think that more than six is.
Not obvious. Everyone likes some margin for error. That serious sites like Facebook, hotmail, Fidelity manage with 6 chars suggests online brute-forcing can be resisted at that level.
> Anyway, many of those sites will not admit to intrusions even when they are aware of them, so your suggestion that "the people who run real sites know..." is spurious
Evidence?
> I suppose the people who run real banks know how to run, err, real banks? Experience of the past few years says they don't!
They knew how to run real banks for their own profit while shareholders got torched. Worked out rather well for them.
.. is to implement a delay before another attempt is permitted. So give people(say) 3 shots at getting it right then force a 5 second delay before try #4, then 10 seconds, then ... well, you get the idea.
So yes, with a computer the size of a planet and the ability to shoot crack attempts at your victim at warp speed may well result in "hopeless inadequate" passwords that are shorter than War and Peace. However, in practice it really doesn't matter. Most of the hack attacks I get on servers is simply a dictionary attack against a list of guessed passwords of popular names.
However, I would say that when compared with social engineering, even a 4 character password (a la a PIN) is still more secure than calling someone, pretending to be "Jack from support" and just asking people for their passwords.
What you're suggesting is an excellent solution for stopping people guessing the password to unlock a stolen car radio, for example, and I think that's what they do: double the delay after each wrong guess.
However, it doesn't work online because it creates the possibility of a denial-of-service attack. I don't want to find that I am unable to log on because someone else has been trying to guess my password. If it prevented me from exercising some share options before they expire, or something like that, I could be very annoyed indeed.
Preventing many guesses from the same source IP is better, but it won't help if the attacker is behind the same firewall as me.
So what you do is create a quasi-unique machine identifier based on the IP address and some arbitrary data gleaned from the browser (such as the UserAgent or HTTP data) - mush that into a salted hash and you will, in most instances, be able to tell one machine from another even if they're on the same network.
This fails only when you're dealing with particularly diligent SysAdmins who have identical images across every machine in their network and keep them all patched up with a group policy - something I've never encountered personally.
... such as identifying yourself to the sentry as being a genuine member of the same army where it would be impractical for each soldier to have a unique secret and a weak form of authentication is acceptable so long as it can be changed on a regular basis.
For securing individual access in the real world we have keys and signatures. Perhaps we should be making more use of their digital equivalents: it might be more appropriate to incorporate the relevant support into HTML 5 than spending time debating which video codec to standardise.
Unfortunately, the people who write the standards aren't the people who have serious web applications to secure, they're largely the OMG ROFL LOLcats Web 2.0 crowd who believe there's nothing private about your data as long as there's a market for it.
I've been advocating secure cryptographically sound encryption technology that for a while. Especially as it relates to banking, though it could be used for many other communications as well.
Unfortunately, and I hate to point this out, even on these forums the level of ignorance is an impediment. We, the technology leaders, are doing a bad job communicating a consistent message to the public.
We often blame users for lax security, but we're as much to blame for not universally adopting better cryptographic authentication technology on our end.
A source of good passwords: strings < /dev/urandom | less
Keep your passwords in a file encrypted with gnu privacy guard, and paste them into place when required. Remembering one 20 letter password for gpg is not that hard. Non-techies can often remember one decent password if they press the key above or to the right each letter of a memorable quote. Requiring users to change their password every month ensures that the password is written on a post-it note stuck on the monitor.
If a site should not need a password, try to log in as 'username' with 'password'. If someone else has not set this up for you, then you can set it up for everyone else.
"Non-techies can often remember one decent password if they press the key above or to the right each letter of a memorable quote"
Ideally passwords are truly random, but since we're subject to human limitations, we often resort to quasi random generated passwords. Just don't make your algorithm public, otherwise attackers can make the same substitution on their end to compensate.
"If a site should not need a password, try to log in as 'username' with 'password'. "
Or try bugmenot.com, handy especially on sites that want to verify your email address.
The HSBC InterNet banking system has three numbers. An InterNet Banking number, Date of Birth and a customer determined number.
Then then they got an attack of the dumb-dumbs and made it possible to remember / prefill the first number. Why, who knows?
Still it's quite reliable as long as you watch your computer security.
As others have mentioned, this research is assuming that the attacker already has access the the password hashes, so the comments about limiting retry-rate and lock-outs, while valid, are not really relevant.
The problem is that a lot of passwords (especially in web sphere) are hashed with MD5 or one of the SHA versions. These are hashing algorithms that are designed to go fast.
The trick is to design a hashing algorithm that runs slowly. And salt your hashes.
The best password schemes combine "something you know" with "something you have". RSA SecurID and other token-based systems have been around for donkey's.
I use a similar system on my PayPal account -- they provided me the fob for $5 -- not exactly a burden. I'd be willing to pay a similar one-off charge for other "sensitive" accounts such as credit card, bank, and mortgage sites.
Or, even better, why don't VeriSign, Thawte, or others come up with a personal ID vetting scheme as a counterpart to SSL authentication for various sites? One-fob-fits-all sort of thing.
I've seen a few post here about websites, and it's nothing to do with remote sites at all. It's to do with local files such encrypted containers that can be pushed down the pci-e bus to a steam processors like ATI or nvidia GPUs.
So unless they can download a copy of whatever is they need decrypting... then brute forcing with a GFX card is pointless, even a CPU can out perform that fattest of network connections, and then there's other mechanisms in the way such as a GUI or x attempts blocking.
...I agree that 6 is more than enough. Usually it is because of poorly designed lockout or delay systems that a password can be bruted anyway.
That being said, I use brutes regularly on "protected" files. If you have the file on your computer, it is pretty much game over on any password. I laugh at people around the office who think the "protection" and "password" they put on their Excel sheet will stop anyone from seeing it. That is the simplest example really. Obviously it is a little more difficult with other file protection methods, but in time they all fall.
On the other hand, from running a keylogger on my own home computer, I've captured a number of friends email and facebook passwords. Just because I can, not that I do anything with them.
"On the other hand, from running a keylogger on my own home computer, I've captured a number of friends email and facebook passwords. Just because I can, not that I do anything with them."
and you've probably broken the law in doing so as I'm sure it'll be capture in some form of interception of communication statute.
Out of curiosity, how many sites allow the original passwords. For example, if you were in the infancy of the web and you were allowed a four character password and it is now 8 characters, are you not protected just by the very fact that the listed minimum is 8 characters so no password brute force is likely to try the old four character password? Or am I wrong about this one?
I sometimes have to keep files and passwords secured for various customers I work with. Sometimes only see them once a year, making memorising a pain. I use TrueCrypt using AES, random keyfile per encrypted file volume, and a password to secure each file in addition to the key. Keep keyfiles on a usb key drive. They have relevant but non obvious names for each client/project.
Then I have a truecrypt volume with another key and password I have memorised. Holds various data that is important, but will not compromise customers' data if discovered/cracked. This also has a hidden volume with another keyfile and password. This hidden, encrypted file holds a file with the passwords for the other systems, with other memorable words so I can link them together.
Not straight forward, but means you can keep them secure and have plausible deniability about storing your passwords. "What master password file? Who'd be THAT stupid! Look, I can show you the contents of my (non hidden) encrypted file, and it's not there." 8o)
stating the obvious.
Guess that's why (at least the banks in the Netherlands) require a hardware device, together with your bank card and code to even be able to log in.
External devices which are completely (physically) seperated from the computer are probably the only way to prevent trojans from creeping in and hacking your accounts.
(Blizzard authenticator anyone?)
Look I gave you guys free and invaluable advise for free.. take it while it's still fresh :D
All well and good, I'll certainly use 12 characters for my online banking. However, I wish newspapers, blogs, etc. would use less strict passwords - used one the other day that needed 8+ characters with numbers and mixed case, for a site with no useful data that I'd probably only log into a handful of times.
And then a whole bunch of attack vectors go away. Not its not a universal solution, and you will still need a phrasebook to eliminate weak phrases and Ithe other two solutions that need to go in lock step are a password vault which can interactively query a website for its passphrase restrictions and generate something strong, now there's a use for SOAP, and or take the manual approach of securing using a passphrase set appropriate to the site.
On the internet you have to believe everything can fail and that includes security, so assume the site you are using will be hacked.
I was lucky enough to use a web site of the French government that lets users choose a password. Considering this was a government web site, and for an important purpose, I chose carefully a rather high-level password.
The web site then happily sent me an email, with the line: "so that you do not forget it, this is the password you choose:" followed by the password, in clear, in a simple email.
Wankers.
Just as information about the levels of speedup often quoted by researchers when GPUs rather than CPUs are used I would point readers to this article which contains references to work done by Intel which show, in problems optimised for each platform, a typical speedup of around 3x
Article
http://www.linux-mag.com/id/7821
Paper (pdf)
http://portal.acm.org/ft_gateway.cfm?id=1816021&type=pdf&coll=GUIDE&dl=GUIDE&CFID=11111111&CFTOKEN=2222222
Extract - "kernels" refers to computational problem sets such as FFT, LBM etc.
"In the past few years there have been many studies claiming GPUs deliver substantial speedups (between 10X and 1000X) over multi-core CPUs on these kernels. To understand where such large performance difference comes from, we perform a rigorous performance analysis and find that after applying optimizations appropriate for both CPUs and GPUs the performance gap between an Nvidia GTX280 processor and the Intel Core i7 960 processor narrows to only 2.5x on average. In this paper, we discuss optimization techniques for both CPU and GPU, analyze what architecture features contributed to performance differences
between the two architectures, and recommend a set of architectural features which provide significant improvement in architectural efficiency for throughput kernels."
The article covers:
1. SGEMM
2. MC
3. Conv
4. FFT
5. SAXPY
6. LBM
7. Solv
8. SpMV
9. GJK
10. Sort
11. RC
12. Search
13. Hist
14. Bilat
All of the above will work with floating point numbers, up to my best knowledge floating point calculation is required for 1,2,5,6,7,8.
Data flow approach is inappropriate for at least 1, 10 and 12....
For heaven's sake how does this workload compare to inverting a key by (modified) brute force, which is generate - encode - compare in a data flow approach in integer and bit operations????
As performance measures of integer and bit-wise operations are required, but performance of floating point operations to memory is given, you compare processors against inappropriate performance measures, here their floating point performance. Thereby you underestimate the required performance of integer and bitwise operations offered by signal and graphic processors by far.
Head banging, HA
Just to remember:
1a) Characters in passwords are NOT uniformly distributed.
1b) The sequence of characters in the password build Markov chains of finite orders (2-8).
1c) a) and b) offer ample opportunities for attacks based on statistics.
2) Printable characters encode about six bits, NOT eight bits as claimed often. A password with sixteen characters encodes about 100 bits, NOT 128 bits as claimed. This password is indeed a billion (!) easier (less effort) to crack than claimed.
3) The available integer performance (NOT number crunching as claimed in article) per buck, driven by improvements in GPUs and signal processors for image processing, has already increased by the factor of 10 million since 1990. About 100 Billion (!) integer operation / second are offered for less then 1000 US $ per graphic subsystem. Some workstation vendors offer nineteen of those graphic subsystems, a cage, a main cpu, disks and power supply for about 20000 EURs, about 27000 US $, yielding a sustained integer performance of about one trillion (!) operations / second.
In summary:
Passwords never reached the complexity/entropy expected, due to inherent limits. Meanwhile enough processing power is available to crack actual passwords in days with high success rate...
Therefor passwords / password based authentification must be regarded untrustworthy....
All I wrote above should be common knowledge here, HA expects.
... strong passwords, of the type where you have to use 7 or more chars, upper- and lower-case, at least one number, at least one non-alphanumeric, etc, is that they're not memorable. Especially when you already carry-around a dozen other username/password combinations in your head. They also stick-out like a sore thumb when (almost inevitably) written-down.
This means that -
- Once the user has been forced to devise one password that conforms to a complex set of requirements (and yet stands at least a ghost of a chance of being remembered), that password will get used on ALL subsequent sites that require a strong password. It may even get used on all subsequent sites of any type.
- It WILL get written down somewhere. The user may be smart enough not to write it in Tippex on the bottom of the mouse mat, but they'll put it somewhere. If I were to encounter a contact in someone's phone whose street name was tHe_sT1G321, or a text file in someone's My Documents containing the text EAT%sh1t%GERVA1S, I'd straight away know I'd found a password.
I have a Router that will only allow me to have the user name "Admin" and of course I can choose any password with that. I have often puzzled why the Rputer manufacturer does not allow the user name to be changed and then it would make things much harder to hack into Router as they would have to get both user name and password correct, whereas at present they can easily know the user name. Why are these manufacturers so stupid ?.
I mean, if someone's going to try and hack an account or accounts rather than pulling the shutters down how about a honeypot?
1 - mal-user using whatever repetitive methods to gain access to an account triggers an alert attended to by a human being (a skilled, intelligent person capable of reasoning things out perhaps?)
2 - said person triggers honeypot so hacker gets access to sandboxed bit of kit with reasonable ID stuff that is purely fictional. Realistic = yeah, Fictional = yeah!
3 - by this time track n trace algorithms are hunting down the source computer using methods of recording stuff acceptable by Police and in a court of law.
4 - honeypot gives hacker access to almost realistic stuff and then starts a network slowdown speedup (you know the sort of thing) with alerts on say transfers might take a while or two because of network overload due to routine maintenance but will be credited back to the source time that the instruction was given?
In other words if the bad guys spoof why can't the good guys?
Please (re-)calculate the entropy of those generated passwords!
Please bear in mind the reduced entropy due to known syllables!
Please bear in mind that a substitute cipher does not change the entropy!
Please discuss the (metric) distance of your passwords generated by your algorithm! How easy will another password be derived from an already known?
Four random characters (your salt) encode at most 24 bits of entropy. How should these help?
Head banging, Hans Adams
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
