jik@athena.mit.edu (Jonathan I. Kamens) (04/11/91)
In article <26522@adm.brl.mil>, IFAC%SNYCENVM.BITNET@cornellc.cit.cornell.edu ( FRANK CALLUCCI) writes: |> I feel that there is a simple way to pick a password without being |> vulnerable to people decoding it. I feel that the trick is to use control |> characters. Control characters cannot be displayed or printed. If you |> were to use the password WIZARD for instance you would use (<CTRL> WIZARD) Using control characters in passwords is, indeed, a good way to make them less vulnerable to attack. |> and there would be no way that anyone could decode it. This, however, is not true. Although most password crackers use a search space that does not include control characters, there is absolutely no reason why control characters cannot be added to the search space. And, as people have been discussing at length recently in alt.hackers, our technology has advanced far enough that it *is* possible to build up huge dictionaries of precomputed encrypted strings, including (if necessary) strings with control characters in the original key, in order to make password cracking easier. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
ronnie@mindcraft.com (Ronnie Kon) (04/16/91)
In article <1991Apr11.135940.8717@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: >In article <26522@adm.brl.mil>, IFAC%SNYCENVM.BITNET@cornellc.cit.cornell.edu ( FRANK CALLUCCI) writes: > >|> and there would be no way that anyone could decode it. > > This, however, is not true. Although most password crackers use a search >space that does not include control characters, there is absolutely no reason >why control characters cannot be added to the search space. Case in point, as I am a security fascist, I wanted to make sure that people were choosing passwords which were not going to be decodable, so I wrote a program which would go through /usr/dict/words and, for each word, would try it, it with a number of common prefixes and suffixes, it with various digits or punctuation marks before and after, with each letter in turn changed to a capital and control character. This approach took on the order of two weeks to run on a Microvax II at priority 20 (as a practical matter, that meant running only at night). On my current machine (a RIOS 6000) I would expect the whole process to run in under 48 hours. The advantage of using control characters or punctuation marks is that it requires a much longer search. But it is far from uncrackable. Best advice I ever heard was to come up with an eight word phrase and use its initials as your password. Thus "To be, or not to be. That is" yields the password "tbontbti" which is about as difficult to crack as anything, and yet is easy to remember. Ronnie ------------------------------------------------------------------------------- Ronnie B. Kon | kon@groundfog.stanford.edu | "I like that everyone becomes food." ...!{decwrl,ames}!mindcrf!ronnie | -- Hobbes -------------------------------------------------------------------------------
martin@mwtech.UUCP (Martin Weitzel) (04/21/91)
In article <671739430.9162@mindcraft.com> ronnie@mindcraft.com (Ronnie Kon) writes: >Case in point, as I am a security fascist, I wanted to make sure that people >were choosing passwords which were not going to be decodable, so I wrote a >program which would go through /usr/dict/words and, for each word, would >try it, it with a number of common prefixes and suffixes, it with various >digits or punctuation marks before and after, with each letter in turn changed >to a capital and control character. [...] >Best advice I ever heard was to come up with an eight word phrase and use >its initials as your password. Thus "To be, or not to be. That is" yields >the password "tbontbti" which is about as difficult to crack as anything, >and yet is easy to remember. A good advice, I think (not only because I used to give the same advice :-)) But of course, a program like the one you describe above could also be adapted to search for the initials of some well known phrases ... Another approach would be to use any word you like, but, when typing it, just use the key to the left (or right) of the correct key But of course, a program which encodes a whole dictionary of words could take common keyboard layouts into consideration and try variations on this approach too ... The problem is: IMHO any good idea on how to construct a good password that is also easy to remember can be attacked if the bad guy knows this idea. But that should not stop us from posting some ideas to achieve the above goal (not in a dictionary but easy to remember). Here are a few more: 1) For someone who programs with C, "To be or not to be ...?" could also reasonably abbreviated to "BB||!BB", or "2*b|~2*b" just to mention two ideas out of many variations (including logic transformations, you might also use ~(~bb&bb) :-)). 2) There are some similarities in the shapes of digits and letters, e.g. 1 -> l or I, 3 or 8 -> B, 4 -> A, 5 -> S, 0 -> O. Replace some of the letters in your password by the respective digits, or, if you use some number as password, replace the digits with those letters. (Using a number is often a bad approach, since normally the numbers you will easily remember - like your phone number, birthdate etc. - will also be known to many others. And now as the above approach is known to them, they might have a new thing to try.) 3) Also, using nick names should allways include slight missspellings (sp?) (or variants like the above ones) and is generally not such a good idea, if these names are currently in use ... but maybe no one in your working environment knows how this nasty boy from the neighbourhood called you when you was five years old ... 4) As we are talking about misspellings: Select one of your favorite misspellings from one of my postings (there should be many ... :-). 5) You also can include into your password some punctuation characters, so that - all in all - they form a pattern which is easy to remember, `:_oo_:' (well, it's a bit hard to type). Finally, some other consideration: Teaching courses I have sometimes during practical exercises to 'su'-login from the keyboard of some participiant. For this case, I prefer passwords that are easy and fast to type. This involves using keys that are located near each other, some with double or tripple key strokes and shift key (operated by the other hand). Even if you watch someones fingers closely, passwords like kkLopPo are not so easy crack. (Of course, this approach is only good if you have to avoid that people crack your password from watching your fingers while you type it a few times during the one week the course lasts. I'm sure that this wouldn't work if they could watch your fingers often enough very and then do some experimenting.) BTW: Watch the fun if you set up a fake-root account with a not too hard to guess password and place someting like stty -icanon; set -n in the respective .profile . The intruder gets in but will first wonder why he or she is not able to execute any command and then detect that it is impossible to logout! (Of course be sure to remove "su" and any other command which changes the account without executing .profile ... and be sure to provide an alternative way to login as root - maybe a second privileged acccount with some other login directory and, of course, a NOT simply to guess password.) I'll close with a short "war story" which really happened some years ago: The company which had hired me as teacher for their courses was also the manufacturer of their own hardware, and of course they used their own hardware. At these days, they had a brand of terminal with a builtin key-switch that could be turned left and right with a small key. Turning it left sent one sequence of characters (Escape-so-and-so), turning it right sent another. Some day, someone% had the "brilliant" idea to use two key-turns as root password and take away the keys from the terminals (to login as root now required to have the key with you). Guess what happened soon after some of the participiants had seen how the teacher supplied the password for root? %: Honestly, it was NOT MY idea, though I confess that I didn't realize the danger at first glance ... -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83