In other news
Yes 7 is bigger than 3!
I'll get my magical coat of 246 alphanumeric password strings..
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 …
Using a keylogger will defeat even the most complex password (assuming it's 1-factor). Well who knew??
Utterly pointless research. Passwords are good and bad and need to be a strong as the need requires. However you will always get an idiot who believes that the most mundane systems require uber-complex passwords. For example, at my workplace, we now have a new online room booking system for meetings. It's hosted internally, behind the firewalls, and the room bookings are free. The password for the new system requires 8 characters, upper and lower, with at least one digit and one special character and needs to be changed monthly. The AD logins have less complexity, so ironically, it's easier to break into a desktop (which you'd have to in order to get on the network to use the room booking).
AC as I'm sure the sysadmins consider this sharing a security breach...
It's the age-old battle between security and usability, and as ever the best way is a balanced approach.
Not looking forward to the start of a new school term with kiddywinks who STILL use an entire sentence as their password (30chars +), then asking for a reset despite being told to use something sensible.
(Though it is quite amusing to watch their red faces when you delete that extra space they'd added after their username in the login box...)
If it were in our domain, yes. It's hosted by a third party, seemingly connected via a VPN (given it appears as an external address, which is inaccessible outside). But otherwise, yes, it should be by SSO - but the majority of our new web services are in the same boat, including travel, service management/workflow, billing, procurement & HR systems. Some hosted internally, but off-the-shelf with very little customisation and no integration in the AD SSO.
You, my friend, have just made the mistake of using common sense in your argument. It's not applicable here it seems :-(
The only problem is with everyone asked to have much longer passwords, a lot of non-technical people will keep all their passwords in a root text file called passwords.txt
If you think thats bad, then just add in they will also need to carry their passwords.txt file with them on a USB stick in their pocket.
What could possibly go wrong.
(Sadly I'm only half joking).
"They suggest that some low-security sites (such as newspaper sites) insist on the use of passwords "primarily for psychological reasons ... as a justification for collecting marketing data and as a way to build trusted relationships with customers". ®"
While I understand that sentiment I imagine any online paper that allows comments or submissions also has a more practical reason, after all if you could simply post under anothers name (as with many blogs I read) you inevitably get some twazzock or another hi-jacking another posters name to troll.
Using the phrase "Best practice" often means I want you to accept what I'm about to say without question. In this case I'd question whether longer passwords help as users, in my experience, tend to change them less often and use recurring patterns as they find them just too much work.
I'd also like to point out that if my login mechanism makes you wait a second between each try and several seconds every third try, extra computing power isn't going to help. OK, you could open multiple login sessions but that's going to get you blocked too. If you've also got to guess the login name then you're going to be there even longer.
Yes, Graphic cards abilities are impressive but I'm not sure it's time to sound the alarm yet.
The attack isn't based on using your login mechanism, it's assuming access to your hashed password file and then computing power does matter. I agree that recommending (let alone enforcing) very long passwords is unlikely to work well in practice. If you have assets that require strong security protection, passwords alone are unlikely to be adequate - you need multi-factor authentication.
It is not that difficult when presented with an actual computer to reboot it into a CD or USB version of micro-Linux, where you can access the password hash file. You can take this offline and decode it, using the heavy GFX mips mentioned (and an intelligent password guesser), or through rainbow tables.
This will normally then allow you onto the machines company network - with only one password guess...
Most if not all business laptops keep a local copy of the password hash, so you can sign in to your open machine when you're off-network. They don't actually have to do it this way, you could have a different password for local use, and a login screen for the company network. This would not require any storage of the company password or its hash.
When someone has a level of access to your machine in order to obtain your password hash they can then crack it. Hardly a leap of faith. Unless I'm missing something, the only use for this would be to obtain access to stored keychains as you already have a root level access to the system.
How does it go when full drive encryption is used?
Most BIOS passwords can be circumvented with a CMOS reset. Admittedly not all of them (Thinkpad's survive that method IIRC), but presumably it's possible to swap out the BIOS and CMOS chips from another identical laptop in these extreme cases (think back to the days when you had to recover a motherboard from a BIOS virus).
However none of this is needed. The more trivial method involves taking a screwdriver, removing the boot disk and mounting it in a separate machine. You can even clone it to an image and hack away at the hash files to your hearts content.
Seriously? Most PC case locks take less than 2 minutes to circumvent if your serious about getting in and have a little know how, a bit longer if your trying to not leave any physical evidence of the intrusion. :-)
All kidding aside though, valid point if you have physical access to the box you have the box and by extension possibly the network it's only a matter of time.
I've worked at places that went to great extremes, even to the point of "disabling" all external ports, in all cased if you really want to get in you can get in. Just like cracking a safe it's just a matter of having three things: 1) The time to get the job done, 2) the right tools and 3) the knowledge of how to use them.
What concerns me the most it the tools are more readily available, faster and easier to use than ever...
Mines the one with the lockpics attached to the USB stick.
Yes. My fileserver is in a case I found in a skip. This has welded lugs and a metal bar to take a padlock. so you'd need a hacksaw or crowbar. ( The dual core Atom ITX board and dinky power supply and disks occupy about a quarter of it.)
Security not an issue with this anyway due to no easy access.
Usually you just have to disconnect the battery to reset the BIOS. In the worst case, you just move the disc drive into another machine.
Theoretically, the drive could be encrypted with a strong key that only the BIOS, or the drive itself, knows. However, I've not come across that. If the drive is encrypted with a password that the user types in, then that can be cracked using GPUs, etc, just like the password for the company network that is in most cases stored on the disc, as someone else just pointed out.
I wonder if this whole digital security thing will be sorted out before I die of old age. I see little sign of progress. It's still only a tiny minority of people who understand and care about the issue.
We need a solution to passwords - I have about 500 passwords in use across many systems and perhaps 50 of these get used regularly. About 10 passwords are "vital" ones such as banking or router passwords.
There are a number of so-so solutions that will collect and protect passwords, but I have yet to find one that is painless to use (yes, please take this as in invitation to suggest products!) so I end up with my browser holding most of them (synced across different computers) and my poor brain holding all the ones that security really matters for. Most of the low security ones to end up sharing the same password, but not the vital ones.
Before long we may need to find a better solution than passwords that we can remember - but are strong enough to resist brute-force because there will be an ever decreasing number of people that can remember the ever increasingly complex passwords!
browser add-on in Firefox/Chrome/WebKit, supports OSX *and* that toy OS from Redmond WA.
took a while to get comfortable with their architecture and with them; but it's been working well for a year now.
makes it easy to end the password-reuse trap even the best of us are prone to; its generator supports arbitrary password length and character-set options; system has as export facility for local backups.
what I really want, though, is an end-to-end idiot-proof simplified UI for setting up SSH authentications. the infrastructure mechanism for creating and using great big digital keys obviously works well enough for people with the technical knowledge to configure and maintain their own server accounts, but is nightmarishly incomprehensible for the majority audience. it shouldn't be that way, and it doesn't have to be.
OpenID was/is a well-meaning effort to simplify things, but it of course has its own issues; its adoption ramp also seems to have stalled.
OK, so it stores your passwords on a remote site, which does make a SPOF, but they are stored with 256-bit encryption, which makes it less likely a brute force attack will find them.
It's fairly painless to set up and use on FireFox - it's also available for Chrome but the UI isn't as good, and it successfully detects the majority of username / password fields (although it struggles with Wikia - it detects but won't autofill the login popup). Although you access your passwords with a single password, it you're smart enough to be using the program you'll probably choose a fairly long master password anyway.
The program also has the ability to generate secure passwords - tell it how long you'd like the password and what characters the site allows (many still don't allow non-alphanumerics, and several impose a limit of <12 characters, with some only accepting 8 letter passwords!), and it'll generate a completely random password, which you don't need to remember because it remembers them for you.
Oh, and you can download the (encrypted!) file of passwords, so even if something untoward happens to lastpass.com, as long as you've got the extension you can still access your passwords.
There's the one that Bruce Schneier made, but I can't remember what it was called. I have a Blackberry, which has a "Password Locker" app; these are stored under a separate key from the one used for the rest of the BB, so you get a password for the app itself, and the crypto's pretty strong. I put there all my zillion passwords, and it's pretty good to date. Backing up also helps in case my BB ever gets stolen :)
Use Ilium's eWallet .. runs on Windows, OSX, iPhone and Android. Has a password generator which I use. They say they use 256 bit AES encryption. Can back up the wallet and save it in multiple places.
Of course if I forget the 12 character password to the wallet I'm stuffed. Not looking forward to the day dementia kicks in.
Beer because my brain cells need it.
There's a well-known credit card company of whom I am a patron. Some months ago they shortened the HTML form on their secure log-in area to 8 characters, saying that that was all that was allowed. This, despite my own password somehow managing to have been set substantially longer. I guess the HTML limitation wasn't consistent across the site.
I complained, saying that 8 characters was not enough. They denied that, claiming all was fine. Just last month they extended the password length again.
Well, I suppose it's a bit much to ask for an admission that their security was lacking in the first place!
Had a similar one with a large Forex company who shall also remain nameless, but given you'd typically be putting 5 or 6 figure trades through it you would hope for security. Nope.
My favourite issue was the block on too many guessed passwords, which was done with... a cookie. Delete the cookie (or ignore it, as you might if you were an automated scanner) and you could retry at your leisure. Unsurprisingly I still make my forex trades by phone.
Brute force password cracking is only as good (or as bad?) as the password entry system it is used with.
For example you could not brute force passwords below 12-digits (in a reasonable time frame) if you can only try once every 10 minutes after you've got it wrong 5 times in a row!
1) Not one per microsecond, but 256 per nanosecond, about 250.000 times more powerful.
2) Not eight bit, but six bit. Requires a just a billionth the effort to invert a pass phrase with sixteen characters.
3) Pass phrases allow attacks by methods based on statistics.
Everything written down in my own article ;->
best, Hans Adams
If you once got access to the encrypted pass phrase ......There are more ways to compromise your pass phrase.
Well known exponential back off might help, if one has to run a dump brute force attack, as those outdated will die it renders this old approach useless (Netware 3.12)....
best regards, HA
Why not spend more time figuring out who needs passwords.
For 90% of what I do I don't want or need a password.
I'd use a common 3 character password if I could, but...
Software and admins increasingly demand longer more complicated passwords AND that I change them regularly.
A big pain in the neck.
Having things such as increasingly powerful graphics processors you can run CUDA crunching on is all very well and good, but kind of irrelevant in the context of web based attacks.
Consider a password which may be between 1 and 6 characters long, alphanumerics, giving a total of around 2 billion options, lets take another mathematical shortcut and ignore the missing digits from the smaller numbers and lets say that each option tried is 6 digits... so for each check you've got 6 digits, lets add 250 bytes for a decent sized HTTP POST header and presume that you're also going to need to send a 10 character login name and, while were at it, the fields will need to be identified so 'user=' and 'password=' add another 14.
That brings it to about 270,000,000,000 bytes to transfer or about 250 GB of upload to the server.
Lets presume that in order to know if you've succeeded in logging in or not you're going to need to receive the response, and for the sake of argument lets say your average webpage being about 15k totalling an additional 28 TB of bandwidth.
So all told you're talking about 28 TB of bandwidth to check all of the 6 character passwords for one user.
Now the question is, if you maxed out the bandwidth of a moderately sized server of the kind you may wish to attack without alarm bells going off all over the place due to the expensive DDoS and IDS protection you find on larger sites.. so let's say that's 10 mbyte/sec... about 3 million seconds to test them all or 30 days.
Using the assumption that somebody wouldn't noticing you sucking up 100% of their bandwidth for an entire month you then have to consider the poor server trying to check all of these details - running a password attack on an offline is all very well and good... but what is a server going to think when it's having its CPU burnt up by handling billions of extra page generations in ASP or PHP or whatever it may be.
Anyway, in summary, it is true that longer passwords are needed... but when you're dealing with websites, how many you can shove down the pipe to be processed by the server is much more important than how you generate the passwords in the first place.
Are we talking password encrypted files or online access?
A brute force attack against an online site should either be noticed, or hit the old 'you've exceeded the maxmimum number of logon attempts' threshold long before even the lamest of passwords is 'guessed'.
Now, of some has a copy of your laptop or other external medium, then yeah... make them take the better part of a day to crack in.
.... but here goes.
How do you compose a long, and hard to brute-force, password for a particular website?
The Free Method
1. Open up a simple word processor. Enter:
2. User Name: All symbols, e.g. (~(("}` Make this as long as the website allows.
3. Password. Think of something unique that associates you with that website (=memorable). Let's take online banking with Southern Sand Bank plc as an example.
Your own personal memory might be "I opened my account with Southern Sand Bank when we lived in Milton Keynes. It was in 1990; it's now bust". That translates into "IomawSSwwliMK.Iwi1990;i'snb"
Save the text file, then copy and paste the relevant strings into the registration page. Keep the txt file safe - job done.
The paid for, but cheap and convenient method:
Install 1Password (was Mac only, but now also Windows beta). Just use it straight out of the box. It's brilliant, and NO, I do not work for the company, and NO, I am not an affilliate!
This method of creating passwords is terrible. I'm probably preaching to the converted here, but obfuscated and complicated passwords are non-portable and unsafe. If you were to lose that file (Hard drive problems, your cat deletes the file, etc) then you've lost access to whatever it is you've password protected. Perhaps worse, if you find yourself on another computer, you're scuppered! I personally believe in a passphrase; several words forming a phrase - easy to remember, portable and can be stored in your head. You could even use several passphrases, based on the website or context in question. "I like to read El Reg!" would be an o.k. example.
Here's a site I stumbled upon earlier saying all this better and in more detail:
Paris: Because "That's hot" is her passphrase.
My password generation technique is easier in my opinion. You take a phrase that sticks in your head, say 'I hate passwords'. Then you mash it up a bit and get something like, 'I h@e passw0rds'. A 15 character password with 3 symbols and a number and mixed case, all easy to remember and difficult to crack. At least with the password crackers I've used in the past.
I occasionally have to do this sort of thing for audits / security checks and if you can get hold of the password file itself (from the local computer or from AD) then simple, free tools such as 0phcrack with the large dictionary (about 700MB) will pull out passwords of 12 unconnected characters in a few minutes. If you get hold of AD then you also get the last 5 or so changes so you can see the patterns people use when they have to change their password. I accept getting hold of the files in the first place may not be that easy, but once you have them you don't need a powerful computer or a long time.
Download a password liberator of your choice and and try it on your computer at home, you will be surprised at how easily your secure password can be exposed. Needless to say, don't try it at work unless you have permission to crack passwords or you know you are clever enough never to get caught.
It's setting up a memorable word as the 3rd step in the process (if you're so upset, realise that subsequently they only ask you 2 letters from this word at login, even less "secure").
As I recall, Barclays are one of the best in terms of security. Bear in mind they're moving to 2FA with their PINSentry devices, and even before that they required your surname, user ID and password before getting to the "enter 2 letters" stage.
It's very easy to pick holes in a system if you only focus on one aspect.
"As I recall, Barclays are one of the best in terms of security"
Oh yes, like they sent a replacement bank card for my mother to an address from which she had moved 3 months earlier. They totally ignored her letter telling them the change of address because "anybody could have written it".
"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:
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
> 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.
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
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:
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.
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
Biting the hand that feeds IT © 1998–2021