Another thing I have never understood about this process is that if I get either the User ID or password wrong three times, I get locked out. How does this not prevent also prevent brute force attacks?
Pshaw! We don’t need no steenkin super-computers! Sherlock Holmes cracked exactly such a cypher in The Valley of Fear
It does. The point about this attack is that you need to somehow steal the database of encrypted passwords, and you try all the possibilities yourself. What has been built to make this more tractable are systems that use GPUs to accelerate the speed of tests, so that very large sets of possible passwords can be tried in a useful amount of time.
Stealing the database can be effected by more traditional means - social engineering, burglary, bribery, corruption and so on. Once you have it the technical attack starts.
One of the standard assumptions in any cryptography is that you can’t assume that keeping the encryption algorithm secret is of any value. Once it is known you lose it for all encrypted data, and you can’t get it back, so any reliance on it being secret is too risky. But history has shown that encryption algorithms and their implementation is a difficult problem to get right. Peer review and open publication of the algorithms and implementations allows for great scrutiny and ultimate quality. Groups that that have invented their own and kept it secret have often found to their cost that they actually have a much less secure system that the open ones.
This kind of attack doesn’t go through the login system. The assumption is that the attacker has somehow gotten ahold of the password file itself. Now, this is something that ideally should not happen at all, but there are still safeguards in case it does happen: What’s stored in the password file isn’t the passwords themselves, but their encrypted hashes. Still, if you’ve got a lot of time on your hands (or more precisely, on your computer’s hands), you can take that file and run it through your own cracking program, that lets you have as many tries as you want. Then, once you’ve found the passwords, only then do you go back to the original system and actually log in.
Seems to me that one trick available to modestly educated folk would be to throw in passwords using phrases containing slang and tricky foreign words. Sure, the individual words are on the internet somewhere, but not likely strung together in just the same way as they could be in a password.
Like Nichtwahrmybonami - and no worries, I promise I’ll never use that one.
This would work? Sort of?
There’s a few of these on the web, once you get to more than so many characters it says it takes quadrillions of years (or more).
A good password system is a variation of the old book code: You pick a sentence that you can remember, like a lyric from a song, and use the first letter from each word. For example:
*If I leave here tomorrow would you still remember me *- **iilhtwysrm
**They’re both very secure and very simple to ‘play’ in your head and type out. Though I’m sure there are people somewhere working furiously to create a database of song lyric word initials…
IIRC - when you try to login, you transmit not the password but the hash of the password. The one place where this is easy to intercept is a public wifi. Hacking the wifi security itself is usually pretty trivial for older (WEP) systems, and not impossible for the latest and greatest.
(The exception is FTP, where your login is transmitted in cleartext. This is why FTP nowadays is discouraged generally, except for public open FTP sites which distribute publicly available files.)
This is why a lot of workplaces prefer using VPN or other end-to-end encryption tunnels rather than connecting on a web page.
Lots of good comments in this thread, but a few things have been missed:
Password attacks as discussed in the OP are made on databases containing user ids and password hashes, and are conducted offline. Generally the hash method is known or implied.
Hashing is a oneway process - information is lost, and hashes are not unique. But a good hash should be unique enough for the plaintext space. Good hashes are never similar - there will be no similarity between the hash for “password” and “password1”.
To attack a password via the hash, you need to have start with your dictionary - the list of words you suspect are used for passwords. This could be all alphanumeric combinations up to a certain length (say 15 characters). Of course, if the passwords allow punctuation, you will never break it based on such a dictionary. The longer the password and the more allowable characters, the more possibilities you have to compute. The simplest approach is just to generate all the hashes for all the possible password combinations, and use a simple lookup table on each hash to find the password. This is very slow and requires vast storage, both at the original generation stage and for each possible password lookup. However, the size of the password does not actually matter in this case.
The better approach is the rainbow table - this uses complex math to speed up the lookup of a hash and the identification of the plaintext by using a precomputed table. This comes at a cost - the precomputed rainbow table takes a long time to generate, and is also large (just not as large as the simple lookup table). Rainbow table based tools usually optimise for speed, and this speed optimisation restricts the size of the plaintext. The tool in the OP now does not have a short length restriction, but at the cost of some other optimisations. However, I’m confident that a pre-generated Rainbow table for all passwords up to 55 characters would take decades to actually generate, and require more than petabytes of storage (15 character Rainbow Tables are over a Tb already). So while the tool could break a 55 character password, there are no tables suitable. You could use the Bible/Collected works of Shakespeare/Wikipedia/Oxford Book of Quotations to generate a limited Rainbow table, but what about War and Peace/Collected Works of Dickens/… I don’t see this as a serious threat to password security.
Also, strong password hashing uses a concept called Salt. This a a string added to the front of the password before it is hashed - so when you set a new password (“password1”) on a site, it does not get hashed as “password1”, it gets hashed as “site1password1”. This means that the password is longer, and the final hash is different on a second site (which would be “site2password1” with a different hash value). The salt is added to the password when it is entered for authentication before hashing. It does not even matter if the attacker knows what the salt is (unless they are prepared to generate a completely new dictionary based on the known salt) - it still makes reversing the hash harder and longer. As for selecting a long, easily remembered password - XKCD has it covered.
Finally, passing a password over an unencrypted http website involves the password being transmitted in the clear - hashing takes place at the server end. Using https ensures that the traffic is encrypted before it leaves your system, and should be used for all public internet access. Secure sites should redirect to https before passing a password over the connection. SSL is not a guarantee - certificates can be compromised to allow man-in-the-middle attacks (used by governments and corporate IT systems), but it is always a good first step. There are plugins for some browsers that enforce https for public sites (Google/Facebook/Amazon…) where possible. They are a good idea.
Does anyone at all use FTP for anything nowadays? I don’t think I’ve seen it for a decade. All the uses which would have used FTP seem to have switched over to scp-based tools, from what I can tell.
I have been using FTP continuously for years to upload to the different websites I maintain. I use an old program, FTP Explorer, which works very well with Windows and has the drag and drop feel of Windows. But I guess I really should get with the times. What software would you recommend as an SCP client? (I am going to assume every hosting service will offer SCP access).
I use it in embedded systems on occasion as a way to get files onto a very minimal linux-based system.
Internally we use FTP all over the place.
Externally we use FTP, SFTP or FTPS depending on the capabilities of the other party.
I’ve used FileZilla and I like it fine. It’s free. FileZilla - Client Features
I’ve also used CuteFTP for the Mac, but an old version: http://www.cuteftp.com/cuteftp/
Yes, and this is sort of covered in the XKCD comic si_blakely linked to. The words don’t need to be slang, or foreign. However, they absolutely must be random. If the sequence of words occurs somewhere then it is not safe. Crackers already have tables of word variations (letmein -> 13+m31n) and so you should assume that just taking a common phrase and replacing words with slang or foreign translations isn’t going to make much of a difference.
By the way, Ars Technica did a whole series of very good articles on passwords and those who crack them. Reading how an apparently strong password like “qeadzcwrsfxv1331” was broken is very enlightening.
When naming your first dog, use at least 8 characters, and a mixture of letters and numbers…a phrase is better than a single name…
It looks like it works with FTP and SFTP but not SCP.
Several thoughts regarding password generation:
I have a file with my passwords encrypted with PGP so I only have to remember the PGP password. This can be cumbersome if you need to access the passwords often and fast but it works for me.
For generating truly random passwords you can use MD5 or other hash so that your password “root” can be formed by a password common to all sites plus the name of the site and then the MD5 is the password. So, my common part can be DirectMartinelli=ObliqueAthena and the password for this website would be MD5(DirectMartinelli=ObliqueAthena@straightdope.com)=2a2a14bec1ff5ab9dc67 (truncated to 20 chrs).
I have an Excel spreadsheet where I put the root in one column and in following columns I get MD5 as well as other combinations with upper/lower case, numbers, etc. depending on what type of password I want.
One way to make easy to remember passwords is to form them with syllables rather than words. Taking random syllables from the text I just wrote: trupassthecan*67Excel. Easy to remember and type.
Another trick is to use a passphrase which is easy to remember but use only alternate characters or one out of three.
NobodyexpectstheSpanishInquisition ~ NbdepcshSaihnusto
Except that isn’t random, it just adds an extra step for crackers to through. Sure, it won’t be among the first passwords that gets cracked, but if you can think if it, so can the crackers.
I disagree. Saying “if you can think of a password so can the cracker” makes no sense. He can think of it if I tell him but I can guarantee I can come up with a password which cannot be guessed on its own. Furthermore, add one more step and put it through a hash algorithm and it becomes random and even more impossible to guess. Now add another step with a secret algorithm and it becomes even more impossible.
You would have to know the original password, already very secure, and know how it was later processed which is something only I know. The end result is as random as you can get.
Still isn’t random. You used an algorithm with non-random inputs to generate it. If you use an algorithm to generate a password the crackers can use same algorithm to try and guess what it is. Sure, if you are the only person in the world who use this particular algorithm the crackers are unlikely to try it, but this is just security through obscurity.
If you want a completely secure password is has to be random and long, not just look random but actually be random.
Let me get this right. You are saying that
GrandPink*567RoseBoy
is a safer password than
274263064b1fab93cb08
And this is safer than
3T1eE12ibdCz427xfVcx
Yes?
Anybody else agree with that?