[Tutorial] - How to Create a Secure Password

Networking/Security Forums -> Physical Security and Social Engineering

Author: NeonWizardLocation: Vancouver, Canada PostPosted: Thu Aug 12, 2004 8:43 pm    Post subject: [Tutorial] - How to Create a Secure Password
    ----
Secure Passwords Tutorial

This tutorial was designed as a guideline for choosing good passwords for computer users. Password security is a very important thing that many people overlook. You usually think about a password as a tiny thing that protects your hotmail account. But what about your online banking, where you credit card number is, or your eBay account? Anywhere you use a password, it is critical that itís a strong password. Password cracking has evolved a lot, there are now very many password crackers available to anyone to download for free, and most users fell back in time on making secure passwords. So whether itís protecting your computer, or online accounts, it has to be a strong password in order for your information to be safe.

What Not To Use

Many users use in their passwords things from personal life, such as:Do not use this, under any circumstances. These things can be easily guessed, and more easily cracked. Never use obvious things from your life, such as names, birthdays or other dates. Anyone who knows you a bit can easily guess your password. Password crackers have all the names, and can try hundred of number combinations very fast. Never use these things in your password.

Password Generators

Password generators do indeed create strong passwords, but they have other flaws. The passwords that they spit out are hard to remember, and take long to type. They are also vulnerable against the password-generating algorithm, which some password crackers might use in order to reverse the decrypting process.

An online example here: http://makemeapassword.com/

The Longer The Password, the Better

In the old days, the characters in a password of an NT box were limited to 14. Today, Windows 2000 and Windows XP allow up to 127 characters as a password. The longer your password, the longer it will take to crack. One thing that was discovered is that if you make a password in Windows longer than 15 characters, Windows does not store the LanMan hash properly. This protects you against brute force attacks of password crackers.

Make Use Of Characters/Symbols

In order to make a strong password, itís recommended that you use all types of characters and symbols.

Code:
Lower Case Ė a,b,c,d
Upper Case Ė A,B,C,D
Symbols - @,#,$,%,^,
Numerals Ė 1,2,3,4
Alt Characters Ė ¬, Ä


It is highly recommended to use a combination of these characters, numerals and symbols. If you donít want to use the Alt Characters, use upper and lower case, numerals and symbols, which will create a strong password, and make it hard for password crackers to break it. One interesting example could be NeonWizard20@email.com, while this might seem unusual to you, this password uses upper/lower case characters, numerals, and symbols. When I put it in a Password Strength Meter, it showed me that it is a very strong password. However, make sure you donít use your real email address. This kind of type is only an example. It uses all the characters and symbols; itís easy to remember, hard for password crackers to break, and no one could even think of guessing it.

Using Space

Passwords in Windows 2000 & XP can use space. It is not recommended to use space at the beginning or at the end of the password. The other downside of it is the sound that the keyboard makes when your press the space bar, and someone can easily tell that you pressed space on your keyboard.

Inversed Words

Some people think itís good to write a word inversed. Such as admin, could come nimda. Password crackers will try to reverse all the words, so itís not a good idea to write inversed words. Itís still easy to crack a normal word, even if itís inversed.

Using Different Passwords For Different Accounts

Why donít all the doors on your street use the same key? Because your neighbours donít want you in their house. Itís the same with you. If someone breaks or finds out a password, you donít want them snooping at your other accounts, such as online banking. Thatís why itís recommended that you use different passwords for different accounts. I donít mean use a different password for every account, but use one for your email and forums, and a different one for banking. But surely, please use a different one for important stuff such as banking, online shopping, or anything that has your credit card number in the account.

If someone is after you, theyíll likely to try to break your email account first. If they find out that, they will try the same password for your other accounts too. In the end, you decide how you want to divide your accounts and passwords, likely due to how paranoid you are.

Writing Down Passwords

If you want to write down passwords, for whatever reason, make sure you keep them locked somewhere, in a safe if possible. Under no circumstances are they to be left on Post It notes, and pieces of papers in your desk. The room/office where your computer is located will be the first place that someone who breaks in will look for a written password.

One reason that you might want to write down the password of the admin is in case he quits, so you can have access to the network. But if you do write it down, make sure itís locked properly.

Public/Office Physical Security

Another issue is keeping your password safe in a public/office workspace. People that walk by could peek at your keyboard while youíre typing. Also, people who sit besides you could peek over at your keyboard. It happens in an environment where are many persons, and getting your password can be as easy as seeing what the person is typing. Thatís why you need to be familiar with your password. If you are, you can type it very fast, and even someone who is looking at your keyboard very close couldnít tell everything that you typed.

Make sure no one stops behind your back, and if you are sitting close to someone, type the password fast and donít let them see the keyboard. Some people arenít even ashamed to look at your keyboard while typing the password.

Convenience Over Security

Many people donít even put passwords on their home computers. I can understand this, because every time you boot up you have to type the password. If you just let the system boot up without any logging on, itís easier. But what if someone breaks into your house, and steals it? Itís going to be very easy for that person to get all your personal info. But putting passwords on people who travel with a laptop is a must. Laptop theft, and misplace happens a lot, and the first thing someone does after they get your computer is try to crack the password.

I think that most laptops today come with tracking devices, and if your password is secure, it could take weeks if not months for a password cracker to break it. This could mean that your laptop could be recovered before they broke your password.

Password Crackers

Eventually, any password can be cracked. But the amount of time it takes to crack a password depends only on how good the password is. If itís a hard one, it could take weeks, and eventually, whoever is trying to crack it, will probably give up after a couple of hours. Password crackers are not sci-fi, as some people would think. Password crackers use world lists, brute force attacks, or both at the same time. Word lists is exactly what the name says, a very long list of words, which are combined in different methods in order to crack the password.

Brute force attacks simple make every possible combination of characters and numerals, until it finds the password. Brute force attacks are very slow, but eventually, they will find the right combination. Probably the most well known password cracker is John The Ripper.

Resetting Passwords

A thing that is widely overlooked by people is the ability to reset passwords. This is probably the easiest way to ďbreakĒ someoneís password. Itís very simple, and even if you do have a strong password, anyone who knows you a bit can easily reset the password, make one of his or her own and take over your account.

It can be done so quickly, here are the steps on how easy you can reset a Hotmail password. So you enter the email address, and type some bogus password. Then it tells you the password is wrong, and you want to reset it. You pick the country, and then you pick the state. Pretty easy if you know someoneís password. There are hundreds of free online directories, such as White Pages and Yellow Pages, so type the name, and you easily get the zip code. This is for US, because if youíre trying to reset someoneís password that lives in Canada, it doesnít even ask you for a zip code. Here comes the part that really matters. How hard is the secret question and how hard is it to answer?

Some of the secret questions are:If you know somebody, even just a bit, you probably know the answer to these questions. So please, after you made your account, change the secret question and the answer. Donít make it easy and take it for granted, because probably the first way someone will try to get your password is by resetting it. Make the answer and the question difficult. One good question that I came across when I was trying to reset someoneís password was: ďOnce upon of timeĒ now this may sound like a fairy tale, but I really got no idea what to type.

There could be a thousand of answers to that. So, if you really care about your password being strong, make sure you make a good secret question and answer. And this is not just for Hotmail, but many other online services use this resetting method, extremely flawless if not used properly.

The Importance of Logging Out

Another thing that can be used to take over oneís account, no matter how strong the password might be, is forgetting to log out from accounts when using a public computer. Some browsers do log you out automatically when you close it, but others donít. So please, if you do use a public computer, always log out from all your accounts.

Finding Passwords

Even if you do have a strong password, it can still be found in other ways, if youíre not careful. Social engineering, the nice way to ask for someoneís password is one of them. This is for those 70% of people that would reveal their password for a chocolate bar, as a study conducted this year shows. Donít give the password to anyone, for whatever they got. Donít give it to your parents, friends, girlfriends, wives, or no one else. If there is a real problem, the system administrator will probably come to you and ask for it. Another way to get a password is through key loggers. Be careful that you donít have one installed on the computer. Make spyware and virus checks often.

Conclusion

The best password is one that you can come up on your own with, not one thatís spit out by a password generator. You must be familiarized with it, so you can type it fast, in case anyone is peeking over at your keyboard. A good password contains upper/lower case characters, numerals, and symbols. Also, it has to be long, 15 characters if possible. Only you can decide what the best password is for you. If youíd like to test the strength of it, please use the Password Strength Meter , or install a password cracker on your system to see how long it takes to figure out the password.

*Edited and reformated by ST*

Author: piccolo_21Location: NYC, USA PostPosted: Thu Aug 12, 2004 8:49 pm    Post subject:
    ----
I read somewhere about rsa and key pairs dont the make good passwords.

Author: Mongrel PostPosted: Thu Aug 12, 2004 10:36 pm    Post subject:
    ----
NeonWizard - Nice Tutorial. Covers pretty much everything I can think of.

BTW - thanks for linking to SFDC on your site too.

Author: ShaolinTigerLocation: Kuala Lumpur, Malaysia PostPosted: Fri Aug 13, 2004 5:22 am    Post subject:
    ----
Hi Neon, good work and welcome to SFDC Smile

I hope you don't mind I took the liberty of reformatting a little to make the article easier to read (just a tip for future writing, also break large blocks of text up into smaller paragraphs, it makes it easier to read and digest, especially for those of us that speed read).

I also added 1 web link in the password generation section and moved it to this section so it can benefit a wider audience.

Cheers

ST

Author: M3DU54Location: Las Palmas de Gran Canaria PostPosted: Fri Aug 13, 2004 7:28 am    Post subject:
    ----
Nice tutorial, and welcome aboard.


RE: Long passwords

You mention password length. I believe passwords beyond a certain length are pretty much redundant due to the compression function of hashing algorithms.

The LM hash is 16 bytes long. This means that there are only 2^128 (around 3.4 ◊ 10^38) unique values for the hash. Just using mixed-alpha-and-numerics (no symbols) we have 62 possible combinations per keystroke, lets call it 64 for the hell of it. 22 such keystrokes offer around 5.44 ◊ 10^39 unique combinations.

Lets compare those two figures...

128 bit Hash = 3.402 ◊ 10^38 unique combinations
22 keystrokes = 5.444 ◊ 10^39 unique combinations

We should immediately notice that for every password of any length (regardless of character set) there is another password of 22 keystrokes or less (using only mixed-alpha-and-numerics-plus2[64]) that will also get you past the login screen. In fact, there may be quite a few, ten or more wouldn't surprise me.

The minimum number of keystrokes to pretty much guarantee a password collision for various sizes of the attackers key set is...

keyset[064] - 22 keystrokes
keyset[128] - 19 keystrokes
keyset[192] - 17 keystrokes
keyset[256] - 16 keystrokes

So, at the end of the day the earlier limitation of 14 keystrokes was not actually so bad. It seems that at 20 keystrokes we are approaching the usefulness of password length in an authentication system based upon 128bit hash comparison. 127 is IMO pointlessly extreme.

I'm not saying that this weakness is easily exploitable, quite the reverse seems apparent. I'm just doubting the effectiveness of 30+ character passwords given the compression function of 128bit hashes.


There is the possibility that I'm missing something important here but I'm sure JustinT will correct me if I'm wrong. Until then I will retain the opinion that passwords with greater entropy than the hash offer very little additional protection. Justin?


M3Dz

Author: Security Hobbit PostPosted: Fri Aug 13, 2004 4:45 pm    Post subject:
    ----
NeonWixard, do you recommend patterns on keyboard?
Example: 87yhji*&YHJI (scores Strong in your password meter).

The password is simply two 'circles' on the keyboard starting at 8, then 7, then y, h, j, and i. You then repeat the circle with [shift] key pressed. You get combinations of all characters. You can easily add a non-printable ascii character at the beginning or end too.
Any combination of patterns would do similar results.

Or are good password cracking apps detecting these patterns in pseudo-dictionary attacks? (well ,they wouldn't be dictionary attacks, but there are so many patterns you can do on a keyboard).

N.

Author: piccolo_21Location: NYC, USA PostPosted: Fri Aug 13, 2004 5:10 pm    Post subject:
    ----
Nice pattern technique, but what about rsa and pass pharses

Author: bknows PostPosted: Fri Aug 13, 2004 5:17 pm    Post subject:
    ----
Regarding secret questions, never answer it according to the question.

For example, what is your favorite color? Answer: Ford Explorer

Sure, it's not as easy to remember, but it's not as easy to guess either.

Pay the price for security.

Author: NeonWizardLocation: Vancouver, Canada PostPosted: Fri Aug 13, 2004 7:30 pm    Post subject:
    ----
Thanks ST, it does look better now.

Thank you for that info MD3U54. I think too that 30+ character password is too much.

I don't think that password crackers can detect those kinds of patterns, but it's not really good to use them. Problem is, you're typing the same thing twice, only the second time you're pressing shift. Password crackers might try that, typing the phrase normal first, then use shift to type it again. But it did score strong. Another thing is physical security. Someone might be looking, and there's a higher chance to see the password when you're typing the same thing twice, only keeping Shift down the second time.

Passphrases are better because usually they have more characters, and easier to remember. But the ordinary passphrase does not include uppercase characters, numerals or symbols. So if you're going to use a passphrase, don't make it an obvious one, and make sure it uses upper/lower characters, numerals and symbols.

RSA and microsoft are going to launch the SecurID in the fall I think. SecurID is good, because it uses two factors for authentification, the random generated number, and also the number given to the user. Maybe the same technology will appear in Longhorn OS. Problem with the passwords today is that any password can be broken in the end. No matter how strong it is, even if it takes months for the password to work, in the end it can be broken.

bknows is right, you should answer the question totally different.

Author: JustinTLocation: Asheville, NC, US / Uberl‚ndia, MG, Brazil PostPosted: Sun Aug 15, 2004 4:25 am    Post subject: Passwords, passphrases, and pseudo-randomness.
    ----
This is conditional on what exactly you're using your passwords or passphrases for; if you're considering the use of either of this as converted cryptographic keys, consider otherwise, because it's not a good idea. Ideally, you should use some type of cryptographically sound method of generating random data (realistically pseudo-random, but cryptographically secure), such as a PRNG, which could be based on either stream or block ciphers, with the usage of a secure hash function. To conclude with that, there is no substitute for a good random value, when it comes to constructing a cryptographic key. Predictable, redundant passwords and passphrases are far too commonplace to cater to any conservative margin of security.

The problem with "password security meters" is that many of them do not take into full account the concepts proposed in information theory; they only "measure" the "security" of a value based on things such as its periodicity or whether or not it adheres to an etiquette for mixing alphabetic-numeric-symbolic characters. Many do not take into account the absolute and actual rates of a language or the formulas relating to redundancies. Most of these fall embarrassingly short of accuracy and give insanely falsified notions of security for user input.

The core field that explores the correlation between cryptographic key length and password and passphrase length equivalents lies within information theory, with the pioneers consisting of Turing, to Shannon, to Cover, et cetera. You'll find the terms, entropy, uncertainty, rate of a language, unicity distance, et cetera, that will prove to be crucial in truly understanding what it means to construct a secure password or passphrase. You'll also find that there are many formulas to derive figures that measure just how much information is contained per character, which ultimately depends on the language in use, its character set, and the associated statistics. This causes the "security" of a value to fluctuate tremendously.

Assuming standard English, you'll see a common rule-of-thumb of assuming 1.3 bits of information per character; that's asking for a little over 196 characters, to correspond to the level of security we would expect of a 256-bit symmetric key, roughly, with that formula. Using alphabetic-numeric-symbolic techniques for your passwords or passphrases will lower that requirement, but not to any significant extent that's more appealing than a solid cryptographic method for key generation. You can achieve sufficient levels of security by converting passwords or passphrases to cryptographic keys, but just to be conservative, your lower bounds should probably be much higher.

You can assume that if the password or passphrase is long enough, and contains enough entropy, the resulting hash value should be random, in terms of statistics. The overall complexity you achieve is limited to that of the hash function you choose, so you want the entropy of your value to match the level of security obtained with that hash function; the maximum level of security is limited to the hash function, however, so you can go overkill (i.e, MD5 gives you a complexity of 2^64, SHA-1 renders 2^80, SHA-256 renders 2^128, and so on and so forth). This is just one of the reasons that using a PRNG is easier and more cryptographically efficient.

Passwords and passphrases have their uses, but cryptographically, they've become insufficient for modern threat models. I've discussed this briefly before. They do have their uses, but where they were sufficiently classically, they've lost appeal, conventionally, for the most part. In fact, when you realize that they are "human memory friendly", you understand the inherent reason they are so widely deployed, so it would make sense that research be done to add security in favor of this; an excerpt from a past thread shows one such cryptanalysis:

JustinT wrote:

The biggest mistake of this system, oftentimes, is relying on the user to be secure. Why do you think dictionary attacks are so effective? There is no substitute for a good, random password or passphrase, but because things that we can comfortably store in memory are more convenient, it's easy to abuse the security margin. However, for cryptography to be appealing, it must be convenient. C. Ellison, C. Hall, R. Milbert, and B. Schneier designed a systematic approach to protecting the password or passphrase itself, using "personal entropy", which involves the answering of certain questions that are unique, or personal. In other words, you encrypt your password or passphrase with the answers of a set of questions, where you can still obtain your password or passphrase by only knowing a subset of those questions. This is probably one of the most promising designs, in terms of usefulness. It's a genius way to both add security to our system of password and passphrase protection and make things easier on the user's memory, but in turn, frustrate an attacker by requiring that he or she knows a much larger subset of data, in order to derive any useful information.


It makes more cryptographic sense to not use them where pseudo-random number generation is applicable, to provide a more conservative sense of obtaining maximum entropy and statistical sufficiency. It's just more routinely trivial, nowadays. You can gain this appeal with much less required value length.

The ideal scenario is to use a cryptographically sound method for key generation, as briefly touched upon above, and a sufficiently secure method for storing keys. If done properly, you won't be so practically worried about raw exhaustive search, dictionary attacks, or the fallacies associated with information theory. An appropriate compromise would be aiming for a scheme along these lines. Making a good password or passphrase is practically achievable, of course, but generating a good pseudo-random value is easier, and often better.

Author: Security Hobbit PostPosted: Mon Aug 16, 2004 1:01 pm    Post subject:
    ----
I will not claim to understand half of what JustinT says, but in all practicality, what can we little people do? I really suppose it depends on the threats, but for a home user only scared of people batch running things like L0phtCrack, then what is a good solution?

I mean, isn't it simpler to have a 'simple' password that has to be changed every week (by simple I mean something that would withstand an attack for a week - btw, how can we check that without spending weeks on our computer running L0phtcrack?) rather than a strong password 14+ characters with numbers-upper-lower-alt-...?

Assuming we use a random password generator for one important password (accepting any of them, ie: no bias at all), then how long should it be? I can commit myself to remembering one of those things I suppose.

Cheers,
N.

Author: NeonWizardLocation: Vancouver, Canada PostPosted: Tue Aug 17, 2004 3:19 am    Post subject:
    ----
For home users, first of all, use a firewall, anti virus and spyware checkers. Don't let unknown software access the net, and make sure you run anti spyware tools, as many of them detect software such as password crackers.

It's better to use a good password, instead of a simpler one. It's not hard to make a good password. one example that i've put up was the email one. It's hard to crack, and uses all the necessary stuff.

I'm not talking about your computer's password only, but also about online accounts. Your computer is in danger when someone physically is there and tries to crack it, presuming someone broke in your house.

Password generators make good passwords, and if you're committed to remembering one of those, that's good.

Use that security strength meter. Your password would have to be pretty strong in order to withstand an attack for a full week.

Author: JustinTLocation: Asheville, NC, US / Uberl‚ndia, MG, Brazil PostPosted: Wed Aug 18, 2004 10:59 am    Post subject: Opinions.
    ----
NeonWizard wrote:

Eventually, any password can be cracked. But the amount of time it takes to crack a password depends only on how good the password is. If itís a hard one, it could take weeks, and eventually, whoever is trying to crack it, will probably give up after a couple of hours.


Sure. Exhaustively searching through a finite value-space is presumed, but a "good" value should make such a task practically infeasible. If it can be compromised in weeks or months, it's a horribly chosen value. Ideally, it should be resilient to dictionary attacks, also. If properly derived, it should set "eventually" to beyond our lifetime, given currently known computational resources (at least in the public sector). This is another good case where derivation by pseudo-random mapping/function/permutation/et cetera would be highly suitable.

NeonWizard wrote:

The best password is one that you can come up on your own with, not one thatís spit out by a password generator.


This is definitely not a concrete statement; it depends on the soundness of the human's philosophy as opposed to the deterministic source. A deterministic cryptographic source that generates statistically random values is often much more secure than what can be conveniently derived by the user. It's conditional, so "best" would ultimately depend on the methodology.

NeonWizard wrote:

It's not hard to make a good password. one example that i've put up was the email one. It's hard to crack, and uses all the necessary stuff.


Actually, that example isn't inherently "good", in terms of the security you would assume it to provide, based on what it "scored." Cryptanalysts generally, oftentimes, have prior probabilistic knowledge before conducting analyses. One problem with your example is that it contains an identifiable structure of redundancy. Although it does use a mixture of alphabet cases, numbers, and symbols, it is constructed of predictable, legible characters. It isn't random-like, at all, so we can rule out a lot of values, as probable candidates.

This can be used as a distinguisher to tell us that not all values are equally likely, under the probability that this structure may have been applied. If this was obtainable knowledge, it could be applied as an aid in drastically reducing the complexity of the value in question. Assuming that many adopt these philosophies for choosing passwords, it will only make the attacks more trivially applicable. Password-choosing etiquette exists because of the redundancy of such structure and the fallacies of not taking that into consideration.

Given particular, information, which could be viewed as quite negligible, it wouldn't be "hard" to break; it would be much more practical than you might think. The point is, there should be no information available about the value for me to take advantage of as prior probabilistic knowledge, in the first place; the value should be as random and unpredictable as possible. Never underestimate the ability of a cryptanalyst to mine for information about plaintext.

NeonWizard wrote:

Use that security strength meter. Your password would have to be pretty strong in order to withstand an attack for a full week.


That "security strength meter" is rather poor; the etiquette for choosing a "good" password or passphrase is much too minimal, to begin with, from a cryptographic perspective, and the actual rendered results do not adhere to the entire etiquette they propose. The "guidelines" they propose are generally good, but far from enough, in terms of being sufficiently random, unpredictable, and resilient to exploitation of redundancies and specialized exhaustive search. To give a true impression of "security strength", it would need to be much more information theoretic.

The problem is - it may be able to recognize a good password or passphrase when it sees it, but not necessarily a potentially bad password or passphrase, because the criteria being analyzed is predominantly generic; generally speaking, this allows good values to render good results, usually, but also allows bad values to render good results. This meter is capable of providing incredibly falsified notions of security, and shouldn't be expected to give accurate measurements.

As far as using password or passphrase protection, it truly does depend on your threat model. Chances are, if your threat is low, you may suffice with a relatively secure, arbitrary value based off of a particular language. Dictionary attacks are extremely realistic and extremely effective, so this is a gamble no sane person should take, where confidential credentials are at stake. It's conservative to assume your threat is greater than it may actually be, even if you only reap the theoretical benefit; this gives you a wide margin of security to play with, if the

We've mentioned techniques, such as "personal entropy", that add layers of security to the process of using passwords or passphrases, but essentially, no password or passphrase scheme is better, in terms of generating a cryptographic key, than one that is randomly generated.

One possible solution is to deploy a utility who's purpose is to encrypt passwords, passphrases, keys, et cetera, so you don't have to be bothered with remembering them all. This would allow you to safely store cryptographically sound pseudo-random number generated keys, and only require that you commit yourself to memorizing one "master" key value; this would also be as random, preferably. Assuming your keys are generated properly and your storage methodology is secure, this is one of the better, practical solutions.

Again, determining your threat model is vital; it's difficult to calculate a conservative margin of security, if you're unaware of the cost of compromise. This is, of course, quite conditional, so what is sufficient is variable. However, for the minuscule cost of generating relatively sufficient random values, and conveniently storing them in a secure manner, it's wise to go this route, where applicable. You can derive good, random keys from passwords or passphrases, but it's generally more secure, trivial, and information-theory-friendly to use a PRNG, or some relatively suitable primitive alternative.

Many of the common applications that still rely on password-protection boast threat models much too volatile to be within the scope of using a password or passphrase; cryptography is capable of providing much more robust protection. There was a time when classical password-protection had very minimal requirements, so it allowed significant tolerance to laxation within the process of deriving these values. However, it is now this obsolete technology, that in some instances, still tolerates this laziness, because it primitively relies on human philosophy, at the potential cost of complete loss of secrecy. Using this protection still has very valid application, but cryptography makes more sense in many cases.

Deriving a value which acts as a passport to privacy is one case where there should be less reliance upon human derivation, and more emphasis on cryptographic derivation, in my opinion. The supporting basis is strong and it makes security much more convenient.

securityforumsusername wrote:

Assuming we use a random password generator for one important password (accepting any of them, ie: no bias at all), then how long should it be?


Reiterating the idea of a threat model, that is certainly what this depends upon. If we're discussing cryptographic threat models, the conservative minimum, in order to achieve the suggested 128-bit security level, is 256 bits; obviously, a 256-bit key would ideally exhibit 256 bits of entropy. In regards to a cryptographic key, this is how long it should be. Proper methodology can make storage both secure and convenient, when handling these keys, as aforementioned.

Author: Security Hobbit PostPosted: Wed Aug 18, 2004 8:02 pm    Post subject:
    ----
256 bit key = ~200 characters. aiaiai.
Now I finally see where you're coming from for crypto keys: basically to get the full benefits of a 128 bits of encryption you need to choose a 256 bits encryption scheme and to mitigate the fact that you need a password to protect your crypto key then in order to achieve the same level of protection that your crypto system gives you, you need to select a password that also achieves the same level of security (in 'bits').

But I was just trying to get a fix on computer login passwords....
Considering that they all use hash functions to store passwords, then how long/complex does the password need to be in order to provide a 'home user' low threat level thing (ie: some hacker/physical intruder gets the password hashes). OK, let me set a criteria: it must be able to withstand a 1 month bruteforce attack from 50 standard nowadays CPUs (hacker with a few little bots).
We remove some weaknesses against dictionary attackes by simply using a pseudo-random password.

Would some of M3DU54's keystrokes limits still apply? (but not using 64 possible keystrokes, but a full 255 ascii characters since I am not against using non-printable ascii).

Again, thanks for your help. I am trying to read stuff on cryptography, but gimme a bit more time Very Happy

Other comments: would a palm pilot be considered as a potential secure storage for passwords/crypto keys? With same limitations as above (ie: would need 200 characters key to obtain real 128 bits encryption security).
I also like the idea of storing half keys (half in the palm, half written on a piece of paper hidden somewhere Wink ).

Cheers,
N.

Author: capiLocation: Portugal PostPosted: Thu Aug 19, 2004 11:54 pm    Post subject:
    ----
securityforumsusername wrote:
256 bit key = ~200 characters. aiaiai.

Actually, it would be considerably less... Considering the standard ASCII representation for a character (i.e. not UNICODE), we're talking 1 character = 8 bits. Thus, 256 bit key = 64 characters.

Still a bit to remember, but at least not 200 Wink.

Author: NeonWizardLocation: Vancouver, Canada PostPosted: Fri Aug 20, 2004 12:02 am    Post subject:
    ----
If the Security Strength Meter is not good for computer passwords, what about passwords for online accounts?

And does anybody encrypt the password on servers for online accounts, such as lets say hotmail or yahoo?

Author: Security Hobbit PostPosted: Fri Aug 20, 2004 8:48 am    Post subject:
    ----
capi wrote:
securityforumsusername wrote:
256 bit key = ~200 characters. aiaiai.

Actually, it would be considerably less... Considering the standard ASCII representation for a character (i.e. not UNICODE), we're talking 1 character = 8 bits. Thus, 256 bit key = 64 characters.

Still a bit to remember, but at least not 200 Wink.


Yes I know, but apparently english language has 1.3 bits of entropy per character, so to achieve 256 bits of entropy you would need 200 characters.... Sad

Maybe it doesn't apply to non-standard characters (such as non-printable ascii, symbols, etc...), I don't know, but if that is the case then indeed less characters would be needed, but I can't answer that.

Author: 0x54 PostPosted: Fri Aug 20, 2004 11:53 am    Post subject:
    ----
NeonWizard wrote:
And does anybody encrypt the password on servers for online accounts, such as lets say hotmail or yahoo?


are you asking how does hotmail/yahoo store your password?

i imagine they store the hash of each password. thats just what i imagine, though.

Author: JustinTLocation: Asheville, NC, US / Uberl‚ndia, MG, Brazil PostPosted: Fri Aug 20, 2004 12:48 pm    Post subject: More thought.
    ----
The "200" figure likely came from an estimate similar to one that I previously made:

JustinT wrote:

Assuming standard English, you'll see a common rule-of-thumb of assuming 1.3 bits of information per character; that's asking for a little over 196 characters, to correspond to the level of security we would expect of a 256-bit symmetric key, roughly, with that formula.


Basically, due to what information theory dictates, in standard English, there is, roughly, 1.3 bits of information per characters. Obviously, there have been various other estimates, with values less than 1.3 and slightly higher, in the range of 2 bits; this, however, is a more consistent estimate, and the formula is more conservative; it corresponds to the actual rate of English, so to speak. Assuming that all characters are equally likely, which in practice they are most probably not, the absolute rate of English, according to the same formula, is around 4.7 bits of information per character. Even then, we're still looking at over 54 characters, to give us a level of security similar to that of a 256-bit cryptographic key. But, because we know English text is much too redundant to be this generous, a majority of the time, we can't reasonably assume such a generous bound; we stick to the actual rate, which is unkind, but realistic and conservative.

This applies to passphrases, generally, assuming redundancies of word-based English text; assuming that you mitigate this redundancy through randomization, the amount of entropy present can be increased. In all actuality, it's not that difficult to construct a password with much better entropy levels than those based on standard English. We can defeat these limitations of information theory, provided that we construct these values with two fundamental criterion - randomization and unpredictability. These are all solid approximations, but I would suggest exploring related theory, for more concrete values and formulas. Shannon gave us a wealth of research.

Also, even though I advocate the use of a cryptographically sound pseudo-random number generator over using passwords or passphrases as sources of derivation for cryptographic keys, I also understand the caveats of improper design. PRNGs aren't the panacea, either. If you incorrectly design and implement a PRNG, the amount of entropy rendered can be just as devastatingly low as if choosing a poor password or passphrase. It requires no less caution. The point is, when you are able to make the assumption that your PRNG is correct in implementation and semantically secure, your results are generally much better and more conveniently attainable.

For an algorithm that takes an n-bit key, we should require that it be given a value that contains n bits of entropy. If this value contains less entropy than n, then our level of security is obviously no greater than if we had initially used a key of that smaller length. Therefore, we fail to meet a general requirement. (If you ideally want something much closer to n bits of security, it's more appropriate to use a value of 2n bits in length) As aforementioned, we increase our chances of doing things right when we ensure that our values have a sufficient probability of being random and unpredictable.

The reason I suggest a PRNG for this assurance is quite simple. It's much easier to place trust in a cryptographic primitive, that is based on components that can be demonstrated, mathematically, to produce statistically random output in a manner that is practically unpredictable and indistinguishable from truly random output, to a certain meaningful degree (i.e., cryptographically secure pseudo-random), than it is to assume that an ad hoc "strength meter", based on some generally good, but incomplete, etiquette, is capable of consistently providing accurate measurements of the actual security of a value, equally.

Again, the most accurate portrait is painted when you consider your threat model. Theory approximates bounds we should aim for, to be at least properly secure, but in practice, we realize that scenarios are much different than general textbook examples. In practice, the realized threat may not prompt for a large margin of security, so you may be able to get away with relatively weak, low-entropy values. However, as a cryptographer, I only view this as an ignorant philosophy, because a threat model is only a conjectured amount of risk you assume to be imminently possible; it's an attempt to be minimal and hope your conjecture holds steady.

So, you may suffice with using proposed etiquettes and "strength meters", in a bulk of your practice, but it's a much wiser, conservative approach to be cryptographically precise and accurate, to the highest degree. Why? Not just for theory's sake, but just in case your threat encroaches your assumed threat model. Many may view being conservative, in the cryptographic sense, as setting larger bounds of paranoia; in fact, although we do set larger minimum bounds, these actually achieve levels of security equal to that of smaller bounds that fail to achieve their goal. In other words, we don't expect n-bit primitives to achieve n bits of security; we realize that n bits of security is more readily achieved with 2n-bit primitives.

This philosophy carries over to recommending a source of derivation for values. We don't rely on human etiquette and so-called security "measuring" tools to render us securely random and unpredictable solutions; we more consistently, and effectively, mitigate these fallacies by using a cryptographic primitive that is specifically designed with those two criterion in mind, with statistically verifiable appeal. I am biased towards being conservative and theoretical, regardless of my threat model; it's a safe tactic. However, my threat model isn't always your threat model, and some folks are minimal and practical, so it's up to the individual.

There comes a point in cryptography where "good enough" (i.e., at least out of the practical reach of dictionary-based exhaustive search), in practice, is all it takes to deter an attacker away and force them to focus on other aspects of the system, which lead to more compromise. It's usually not related to the cryptography itself, when you account for most successful exploitation. I don't live by that "point", but it certainly seems to be a popular argument in such debates. The best keys aren't password or passphrase-based; they are randomly and unpredictably generated by an algorithmic process. Based on the constraints of your threat model, determine how meaningful this is to you, in regards to the margin of security you wish to achieve.

Author: capiLocation: Portugal PostPosted: Fri Aug 20, 2004 8:13 pm    Post subject:
    ----
securityforumsusername wrote:
Yes I know, but apparently english language has 1.3 bits of entropy per character, so to achieve 256 bits of entropy you would need 200 characters.... Sad

True; when I said what I said, I was assuming you would use a random (or rather, pseudo-random) key - not just English words. If you use a strong pseudo-random number generator to achieve a key of 256 bits, you can represent that key in 64 characters - that's all I meant.

Author: GreatisLocation: Montego Bay, Jamaica PostPosted: Tue Aug 24, 2004 3:29 pm    Post subject:
    ----
Very informative tutorial and placed in the right section too.

Author: AdamVLocation: Leeds, UK PostPosted: Wed Oct 06, 2004 5:34 pm    Post subject:
    ----
One of the ways we have found our users are happy to adopt is using initials of a phrase well known to them (maybe song lyrics or a poem). Just a couple of tweks for capital letters or replacing letters with numbers generates a password which is:
1) easy to remember and therefore reproduce, so they are prepared to use fairly long strings
2) very hard to guess or shoulder surf (anything which contains real words allows your brain to fill in the gaps - how easily can you recognise the word *ol*d*y ?)
3) relatively hard to crack.

eg:
F!Iw2l4e!
Idoaw25 12
Hmrmamwd?

Author: alpinelegend PostPosted: Wed Oct 06, 2004 6:03 pm    Post subject:
    ----
I think i better change my password now Embarassed

Author: mightB PostPosted: Thu Oct 14, 2004 3:58 pm    Post subject:
    ----
is not more secure to have a password that is word from another language, so that it wont be prone to [English] dictionary attack?

Author: Karina PostPosted: Thu Oct 14, 2004 6:14 pm    Post subject:
    ----
i speak another language. i use that language to generate passwords and/or passphrases. but not everyone has that luxury.

problem with passphrases is that there are similarities.

aa lot of passphases use "to" or "too" and a lot of ppl replace is with a "2".
same with "for" replace with "4"

so there you go. you already potentially know one ot two characters.

Smile

Author: moner PostPosted: Fri Oct 15, 2004 5:04 pm    Post subject:
    ----
thats the usual convention replace "i" with "1", "e" with "3" etcetra, i wonder if the nsa or whoever have a dictionary based on that, it will be intresting...

Author: NeonWizardLocation: Vancouver, Canada PostPosted: Sun Oct 17, 2004 6:01 am    Post subject:
    ----
mightB wrote:
is not more secure to have a password that is word from another language, so that it wont be prone to [English] dictionary attack?


A word from another language is good only if someone is trying to find out the password using an english based dictionary. But in countries such as Germany, and Russia, they most likely have their own based dictionary on that language for finding passwords, as most people that live there won't use english as part of their password.

Author: jasonr1023Location: Long Island, NY PostPosted: Wed Oct 20, 2004 5:31 am    Post subject:
    ----
mightB wrote:
is not more secure to have a password that is word from another language, so that it wont be prone to [English] dictionary attack?


I would not assume you get more security. If I know that you speak another language, and I was after your password, I would simply add a dictionary of the language you speak... =)

I may also add a dictionary if I think I can guess what languages you might know.

Author: Karina PostPosted: Wed Oct 20, 2004 10:02 am    Post subject:
    ----
Quote:
I would not assume you get more security. If I know that you speak another language, and I was after your password, I would simply add a dictionary of the language you speak... =)

I may also add a dictionary if I think I can guess what languages you might know.


well, you have a very good point there, nothing is ever 100% guaranteed to be 100% secure.

Except, for proffessor Ranum's 100% secure firewall solution:
http://www.ranum.com/security/computer_security/papers/a1-firewall/index.html

Razz

on a side note: i recently saw someones sig. on another forum that read, "there are 10 kinds of people in this world. the ones that understand binary and the ones that don't". it cracked me up.

my point to this is: programmers spend too much time behind the computer and not enough interacting with people. just as there is "slang" on the english language, there is "slang" also in foreign languages, which can not be found in dictionaries.

Author: AdamVLocation: Leeds, UK PostPosted: Wed Oct 20, 2004 12:52 pm    Post subject:
    ----
we have people at our firm who speak other languages and I always include those dictionaries when auditing passwords.

dictionaries available easily include things like cartoon characters, film stars and TV personalities, and these are oftne available for local areas too.

That said, because we force complexity some of our users now have reasonable passwords, so we use a variant of the brute force approach - rather than brute-forcing against the password hashes, you use the same sort of algorithm (ie cycle through all the combinations of characters you want to include) to pre-generate a dictionary of "random" sequences. This takes AGES. But this time is spent once, not every time you want to do an audit.

Files for the dictionary are immense if you use high length and many characters, we usually pick a "sensible" factor for these (all A-Z, a-z, 0-9, a few of the more common characters ?!), and length of 9 or 10. Our objective is not to break the passwords, but to identify anyone whose password could be easily broken in a "short" time and send them reminders of good practice.

(and thanks for the sig appreciation - I am told it is attributed to Jeremy Paxman, don't know if that's true but I like its elegance)

Author: ShaolinTigerLocation: Kuala Lumpur, Malaysia PostPosted: Thu Oct 21, 2004 5:00 am    Post subject:
    ----
I pwned that phrase long ago:

http://www.cafepress.com/sfdc.6988208

Author: mightB PostPosted: Fri Oct 22, 2004 3:04 pm    Post subject:
    ----
what are the likely, practical [or even theoretical would be nice to know] attacks on a pass phrase that someone like a Government agency would carry out, like brute force, links, explanation types of attack would be nice thanks again

Author: Mongrel PostPosted: Fri Oct 22, 2004 4:25 pm    Post subject:
    ----
A little balance here. We have been discussing the bits and bytes,
difficulty in cracking, etc - in gorey detail.

Let's get down to brass tacks - we who manage networks and user
accounts need to give our users tools to pick a secure AND easily
rememberable password. One that does not need to be written down. One
that we do not need to reset weekly for the poor slob who makes things
too difficult on themselves.

Sooooo - that in mind - let me share my tricks - that I teach people - that
make passwords that are pretty damn strong and that they will never
forget.

The best part of it is that:

It CAN be a date
It CAN be a name
It CAN be something everyone knows about you

And STILL be difficult to crack.

Mind you this example isn't the greatest but certainly gets the idea across.
And I did LC4 this one once and it took a very long time to crack.

My present passwords, using this technique, have been run against LC5
for three days and not been detected. I got bored with waiting for it to
finish.

I'll take you through one I made for myself and show you how it works.
I'll be interested in the experts replies both in mathematical/scientific and
practical aspects.

Sooo - anyone who knows me well knows I like beer. If you REALLY know
me you know I used to drink Schlitz Malt Liquor (back in the '70s B4 it
was a racial thing). And everyone who knows me knows the year I
graduated High School.

Soo - onward and upward

Rule #1 - No words in any dictionary, names, places, things, brands.
(Baaaah Humbug on this one)

Simple solution - misspell a word, name, place, thing, or brand sufficiently
that it is not a real word but not so much that you forget it

Rule # 2 - Use lower case, caps

Simple solution - use both in your misspelled word(s)

Rule #3 - Mix numbers and special characters

Take that date and shift a couple characters.

19ShlitsMault&#

This is a password I will NEVER forget and passes all the rules of length
and complexity for any corporate environment, probably military
applications, and even if you know me you will be hard pressed to guess
that one in a million years.

Try it once - you'll like it - and teach your people

Author: dataLocation: India PostPosted: Sat Oct 23, 2004 11:08 am    Post subject:
    ----
NeonWizard wrote:
mightB wrote:
is not more secure to have a password that is word from another language, so that it wont be prone to [English] dictionary attack?


A word from another language is good only if someone is trying to find out the password using an english based dictionary. But in countries such as Germany, and Russia, they most likely have their own based dictionary on that language for finding passwords, as most people that live there won't use english as part of their password.


Actually, every language has its on set of frequencies over alphabets as english does. It would mean that some one who has done a statistical analysis on a given language would be correctly able to decrypt the language(based on a frequency analysis for simple ciphers). He needn't learn to speak or write the language to 'crack' it.

Data.

Author: JustinTLocation: Asheville, NC, US / Uberl‚ndia, MG, Brazil PostPosted: Mon Oct 25, 2004 6:31 am    Post subject: Even more thoughts.
    ----
Indeed. Frequency analysis is a rather general way to statistically look at occurrence probability, so if you know what to expect, you can often exploit that quite well. One decent example of foreign language statistical analysis, for a dictionary attack, is as follows, quoting:

JustinT wrote:

Consider an extension of a dictionary attack, where foreign languages were considered. This particular statistical test involved the Pinyin Romanization of syllables in the Chinese language, in regards to Chinese users. Basically, syllables were combined to form one-syllable, two-syllable, and three-syllable words. Because the aim of this approach was exhaustion, whether or not these words were legible made no difference. As such, the statistics of the Pinyin Romanization system are this: 298 Chinese syllables form the system, indicating that there are a total of 158,404 two-syllable formations, and over 16,000,000 three-syllable formations. I won't go into the semantics of this attack, but I mention it because of the relevance to similar methodology that can be mounted against the English language. As you can see, knowing the environment aids in narrowing the field down, quite significantly.


Statistically, using a foreign language doesn't buy you as much as you might think; there are clever attackers out there and if they want to divulge a secret, they'll flex their capabilities. Practically, depending on the reality of your threat model and environment conditions, it may make actually thwart an attack, assuming your attacker is average, dull, and lacks ingenuity (i.e., using a canned utility to search very general, limited dictionary listings, for legible English only). This goes as well for deliberately misspelling words or phrases, or using nonsensical formations. However, this is making a risky assumption, especially since dictionary attacks are so extensive and successful in practice. This risk is akin to saying, "I can get by with 40-bit keys", because your threat model is lenient enough; this makes the assumption that an attacker won't ever exhaust such a key space, which is possible, trivial, and a threat, even if improbable. The idea is to be conservative. Since bits are inexpensive, and being responsible is actually an easy habit once gotten the hang of, there's no excuse not to be. So, despite what "should get by", I think it's best to approach it from a "just in case" angle.

Mongrel wrote:

It CAN be a date
It CAN be a name
It CAN be something everyone knows about you


While the methodologies you mentioned below the above quote might suffice for many situations, it's my opinion that one should refrain from the above generalizations, especially if it will be taken literally, without any additional considerations. First, dates are limited to a small space, complexity-wise (at least considering past and present dates, but still predictable); names are often abused and predictable, statistically, as well. Information known to additional parties can often be detrimental; it's usually wise to limit this, and retain as much uncertainty as possible.

Since dictionary attacks have become so incredibly extensive, the above tactics may fall far short, because of their predictability. So, if they are to be used, it would be best to follow the extra "obfuscating" steps mentioned further in that post. It adds complexity; it may add just enough to thwart an attack. I'm positive Mongrel knew this, and for those reading - please read the entire post, as taking it out of context may mean the difference between glad, or you've been had! I've mentioned about all of my thoughts on this, here, here, and here, so that about concludes everything. There are very clever ways of being innovative and effective with personal information used for access control and cryptography; if you can integrate random, unpredictable values within that - all the better.

Say, close friends know that I'm a huge fan of the Cincinnati Reds. If an attacker knows this, and knows my policy for selecting passwords or passphrases, this may provide information in regards to the probability of likely values, assuming my policy allows me to use information known to others (which is doesn't, but we'll just assume it does). This may be exceptionally risky, considering that sports teams, players, and memorable figures and dates are common choices. Some diehard fans of certain bands are prone to using track names, or obvious variations. If the attacker knows the range of what a particular password is limited to, this make reduce the uncertainty of possible values, in regards to which are more probable than others.

One tactic that may be cumbersome, and is likened to how we view cryptographic keys, is the idea of making any value equally likely. Try to make any value equally likely for a given password, as well as any password for any other account or system that requires such. Never fall into a trend or predictable method for choosing values; this is information that can be used against you. If an attacker happens to divulge one or two passwords, and knows this, he may apply this to others as well. Social engineering works quite well. This may be an extreme, but if you're going to bother with security at all, assume that worst case scenarios are part of your threat model.

The problem isn't only the user; it is equally the fact that systems still using password or passphrase protection often do not demand enough or allow the flexibility to apply secure, yet efficient, techniques. So, until this is addressed systematically, the most secure measures are going to be much too cumbersome for the average Joe, thus limiting the options. Albeit decent, in some cases, an often overlooked fact is that humans not only use systems - they design them. So, responsibility is a two-way street.

Author: Mongrel PostPosted: Mon Oct 25, 2004 11:08 am    Post subject:
    ----
Good points JustinT - re: reading the entire post and making sure
to read, practice, and test the obfuscating references yourself. And mind
you this is for joe average in a simple corp environment. It may well be
written in policies that one may not under any circumstances use
any personal information thus rendering my techniques useless.

And I'll take time to read your previous references on this topic.
Thanks for putting them nicely in one place here.

Author: stevensfoLocation: Italy PostPosted: Tue Oct 26, 2004 8:56 am    Post subject: Hiding a long random password
    ----
Hi,

I've just found this forum, and I'm really indebted to you all for the excellent advice.
Like the previous poster, I use foreign words and phrases as passwords and never thought there was a problem.

A while ago I downloaded Axcrypt which also produces a 44 character random password if you want one. Is this a bit of overkill?
However, it got me thinking about how would I store such passwords if I used one.

I came up with 2 ideas:

1. Save a webpage (I tried with bbc.co.uk) and right-click on it. Select 'View code' to open the html code in Notepad. Simply insert your password between <!-- and --> and then Save changes. Who would ever think of looking there?

2. Most people nowdays have a digital camera and thus thousands of boring holiday snaps on their PC. Simply use a free steganography program to hide the password inside a jpeg.

Overkill perhaps... but all good fun!


Steve

Author: moner PostPosted: Fri Oct 29, 2004 10:06 pm    Post subject: Re: Hiding a long random password
    ----
stevensfo wrote:
Hi,

I've just found this forum, and I'm really indebted to you all for the excellent advice.
Like the previous poster, I use foreign words and phrases as passwords and never thought there was a problem.

A while ago I downloaded Axcrypt which also produces a 44 character random password if you want one. Is this a bit of overkill?
However, it got me thinking about how would I store such passwords if I used one.

I came up with 2 ideas:

1. Save a webpage (I tried with bbc.co.uk) and right-click on it. Select 'View code' to open the html code in Notepad. Simply insert your password between <!-- and --> and then Save changes. Who would ever think of looking there?

2. Most people nowdays have a digital camera and thus thousands of boring holiday snaps on their PC. Simply use a free steganography program to hide the password inside a jpeg.

Overkill perhaps... but all good fun!


Steve


would you like to recomend any steganography software? i cant seem to find any that is worth the while, anyones comment, suggestion, or recomendations will be welcome

Author: stevensfoLocation: Italy PostPosted: Fri Oct 29, 2004 11:51 pm    Post subject:
    ----
Moner,

There are plenty of programs out there. Just do a search.

However the best free program I found is GRLhidden. This hides files in almost anything and is the only 'free' program that I know which can hide files in jpegs.

I use it for hiding my password.

I've also tried S-tools and Securengine, but they are not as versatile.

Have fun!

Steve

Author: capiLocation: Portugal PostPosted: Sat Oct 30, 2004 4:52 am    Post subject:
    ----
stevensfo wrote:
However the best free program I found is GRLhidden. This hides files in almost anything and is the only 'free' program that I know which can hide files in jpegs.

I'd be very wary of using that program if I were you. In fact, I would not recommend it at all. It's method of hiding is anything but "hidden", in fact under some circumstances, the supposedly "hidden" information is right there in plain sight!

Do the following to test for yourself:

  1. Make some example text file, just something like "blabla this is a test, my super hidden password is xxx"
  2. Use GRL to hide that sample file inside some other file. Put in whatever 5 letter code you want. Do not select "compress" in the end. This is only so that it will be easier to see the huge flaw in design of this program (that it just takes your data and appends it to the target file); if you compress it, the data will be slightly harder to identify of course, but nothing a determined attacker can't get past (in fact, the 5 digit password is never compressed, so the all the attacker would need to do is just use GRL himself and un-hide the whole thing).
  3. Ok, now that it's done it's "thing", open the output file with any hex editor. Go to the end of the file, and voilŠ, the entire contents of the supposed "secret", in plain text!!

All this program does is take the data and append it to the end of the file, without altering it in any way. The only way it'll change the data in any (very minor) way is if you choose to compress it. Even then, the 5 digit password is right there in plain text, so it's a trivial matter for anyone to un-hide it using the very GRL program again.

So, first of all, this isn't stenography at all - all this program does is put the data in the end of the file and nothing more. And even with the "compress" thing, it's still not stenography, it's just data "compressed" (with the password readily available in plain text just before the data). And even disregarding the plaintext password issue, this is still not stenography, at best it would be a poor form of cryptography (cryptography = scramble the meaning of data, stenography = hide the very existance of data). Anyone can look at the file and readily see the difference.

Author: stevensfoLocation: Italy PostPosted: Sat Oct 30, 2004 9:26 am    Post subject:
    ----
Capi,
Thanks for that piece of information. I had no idea!

So, which is the best free program at the moment? I liked GRL because it used jpegs. The others require gifs, bmps and wav sound files.

Recommendations?

Steve

Author: JustinTLocation: Asheville, NC, US / Uberl‚ndia, MG, Brazil PostPosted: Sat Oct 30, 2004 11:21 pm    Post subject: Precedence.
    ----
Perhaps you mean "steganography", instead of "stenography?" Either way, simply hiding plaintext in a predictable manner is dangerous. It's like hiding your cash in the back of your top drawer, instead of just out in plain view on top. It's not going to buy you much. I wouldn't say the definition of steganography explicitly requires that you hide encrypted information, but it would be foolish to not ensure that the existence you're concealing is that of data protected confidentially and with integrity. Otherwise, it serves very little purpose. So, perhaps this satisfies the act of "hiding" it, but it doesn't do it very well, and to think it provides any sense of security is a misguided notion. For it to be effective for its purpose, it must be meticulously deployed and with realistic expectations.

In a sense, using steganography to conceal cryptographically-protected information gives you the opportunity to apply the cryptography that adheres to Kerckhoffs's principles, while concealing the act it with entire opposite strategies. "Obscuring the existence of security" rather than security through obscurity, in other words. However, you should never rely on steganography to protect your information; the object is to delay what information is known to an attacker, but we don't design cryptography to rely on this because we know it buys us very little. As we've discussed in the past, steganography probably has more of a political stance, then a role in most conventional systems, in regards to a required design criterion. So, you're either using it because cryptography is abhorred and you must conceal it, or because you just fancy the idea of delaying an attacker's ability to divulge ciphertext he may use to perform cryptanalysis. Either way, it shouldn't be an integral part that one relies on, semantically; rely on cryptography, and devote your faith and precedence to getting that right, first and foremost.

Author: bknows PostPosted: Tue Nov 02, 2004 7:47 am    Post subject:
    ----
I mostly agree, but the only advantage that I see that steg has over crypto is that crypto screams out that you have something to hide. Steg just says, "Isn't my doggie adorable?""

So to resolve this crisis, hide all your encrypted stuff in stegged files! Razz

Seriously, if you encrypt files, make sure you have some junk files that are encrypted too. Some good ole encrypted white noise. Or encrypt lots of junk files and just steg the real stuff. Your attacker will spend their time focusing on the crypto...kinda like the story about the guy at the construction site who at the end of everyday left with a wheel barrow full of sawdust. The guard searched and searched the dust everyday wondering what he was stealing and found nothing. Finally after 2 weeks, the guard figured it out! He's stealing wheelbarrows! (and another one's gone....and another one bites the dust, heh heh!) Embarassed

Author: JustinTLocation: Asheville, NC, US / Uberl‚ndia, MG, Brazil PostPosted: Wed Nov 03, 2004 4:57 am    Post subject: Understanding the limitations.
    ----
bknows wrote:
I mostly agree, but the only advantage that I see that steg has over crypto is that crypto screams out that you have something to hide. Steg just says, "Isn't my doggie adorable?""


This is valid, just because it's only fair to cite contrasting "advantages", even if out of context. However, the condition on which this is valid is a very weak condition, at that, because you're forced to assume that steganography satisfies the same application, which it doesn't. In other words, if we assume that either cryptography or steganography are suitable for protecting data, then we assume that steganography has the advantage of concealing existence, over cryptography, which doesn't; this is the dangerous assumption, since steganography doesn't protect data, but rather, just doesn't wave the idea around that there is data being protected, or assumed to be.

It's a contrast, but not a supporting factor in choosing either. Refer to the principles of Kerckhoffs's; it's easy to draw the analogy that cryptography is founded on those principles, while steganography defies them. Good cryptography is that of open nature, built with resilience to known information in the hands of an attacker; steganography is a clever way to reasonably conceal that information, in an attempt to delay what is known and the complexity of making it known. So, at best, steganography is a complement to cryptography, and an optional complement, at that. In hindsight, due to how we must assume conditions to be in practical security, the alleged advantage isn't really an advantage at all.

It's akin to arguing that some modes of confidentiality are more tolerant to integrity failure than others; this is true, if you assume integrity to be a function of a mode of confidentiality, but such an assumption is dangerous, as modes that are only confidentiality-aware provide only that, and do not satisfy the issue, or even mitigate the problem. Because of that, authentication is integral, just as much as encryption. So, these so-called advantages are left with no bearing at all. They aren't significant enough to fulfil the criteria imposed by proper assurance of data integrity, nor is steganography a satisfying solution to the proper assurance of data confidentiality or integrity.

Quote:

So to resolve this crisis, hide all your encrypted stuff in stegged files!


My above comments were just opinionated "caveats" for the general audience to consider. I say this because I understand your comments were more general, and not so rigorous in the detail of conditional assumptions, but I'm sure you're aware of the limitations. So, I agree, if you're going to use steganography, apply it to data protected by cryptography. Unless there is some militaristic requirement, or political crisis that renders cryptography a "bad science" in your particular nook of the globe, and because cryptography, as a whole, should be built to cater to the needs of information confidentiality and integrity, conventional systems shouldn't require steganography at all. Many can't, given their tight constraints.

If it's to be used, it should be understood that cryptography is still a necessity, and the limitations of steganography are far too monumental to substitute the former with the latter. Besides, a clever attacker will exploit user irresponsibility in non-cryptographic areas, or the handling of cryptographic parameters; implementation has a better track record, in regards to failing, as opposed to the actual science being implemented. So, information security is a pipe-dream, at its practical climax; it's going to take much more than rigorous cryptography to protect information. Adversaries take advantage of this shortcoming and are often left with open doors not related to the cryptography at all. It's like leaving your windows up, but confiding in the doors constructed from tungsten and protected by the most sophisticated of locking mechanisms. Almost a laughing matter.

Author: bknows PostPosted: Wed Nov 03, 2004 7:26 am    Post subject:
    ----
You didn't comment on the junk crypted files. You missed an opportunity!

Yes, Mr. K's complaint was too many secrets, and that's bad for security. We want security to be tested! My comments were mostly tobacco-in-cheek with some serious drool dribbling out.

Of course, most good forensic tools will easily find stegged files, files with extensions that were changed (.xls to .jpeg), and any crypted files. However, most folks we're battling against don't run around with forensic tools in their back pocket. Wouldn't you agree that most of those we want to keep out of our files are those who take a quick peek and don't have the time or the skill to "practice cryptoanalysis" (as you might phrase it) nor know anything about stego.

The bottom line is that we only need to apply the security protections that most closely match the risk, and not a XOR'd bit more. Of course, you could say we need to protect ourselves from ninja assassins, but who's seen one of those lately in the civilized world (which is getting smaller by the way).

If you just want to keep the stuff from your Mom's eyes, fine. But if it's critical stuff that you carry around on a mobile device, then perhaps some heavier soup would be appropriate.

Author: moner PostPosted: Thu Nov 04, 2004 10:32 pm    Post subject:
    ----
can someone help me understand how password cracking or brute force works? how does a program know that a particular password that has been found is the correct one? e.g say my password was "pass", how would the computer program know that it has hit bulls eye for e.g for a pgp disk or something else...i know it might be basics for most of you but I don't know

Author: dataLocation: India PostPosted: Fri Nov 05, 2004 10:51 am    Post subject:
    ----
moner wrote:
can someone help me understand how password cracking or brute force works? how does a program know that a particular password that has been found is the correct one? e.g say my password was "pass", how would the computer program know that it has hit bulls eye for e.g for a pgp disk or something else...i know it might be basics for most of you but I don't know


The computer internally may use a comparator circuit.
Otherwise,
For e.g. we could use an xor scheme.

if A=B, A Xor B =0. So,if we do an xor operation,and the result in the stored register is zero, we know A=B. If the register value is non-zero, we know the comparison strings are unequal.

Data.

Author: AdamVLocation: Leeds, UK PostPosted: Fri Nov 05, 2004 12:15 pm    Post subject:
    ----
moner wrote:
can someone help me understand how password cracking or brute force works? how does a program know that a particular password that has been found is the correct one? e.g say my password was "pass", how would the computer program know that it has hit bulls eye for e.g for a pgp disk or something else...i know it might be basics for most of you but I don't know


When the encryption scheme is known (although a decryption method may not be known or may not even exist) then the password cracker does what the normal system would do.

For example, on a Windows network, when you change your password, it is encrypted and only the encrypted version is stored, never the plaintext. When you log in, your password attempt is encrypted and this is compared with the stored encrypted copy.

SO, the cracking tool does the same thing - it makes up a word to try (or a set of random characters) and then encrypts this and compares with the encrypted hash which has either been taken off a server or possibly sniffed from the network.

Does that make sense?

Author: JustinTLocation: Asheville, NC, US / Uberl‚ndia, MG, Brazil PostPosted: Fri Nov 05, 2004 10:26 pm    Post subject: Conservatism and dictionary attacks.
    ----
bknows wrote:
You didn't comment on the junk crypted files. You missed an opportunity!


This seems to be a further step in obscuring the actual information, but given certain constraints, this might not be a practical option. For conventional systems and protocols, there oftentimes isn't enough leniency for extra "junk." There is also the imminent threat that an attacker will be a bit more clever than to just stare at encrypted junk files; adversaries at home with cryptography are more likely to exploit irresponsibilities in parameterization and/or implementation. If your threat model is that minimal to make the assumption that an attacker isn't that clever, then perhaps you have more breathing room. For the average home user - probably so.

Sure, we need to instantiate a solution that satisfies our threat model, but in cryptography, it never hurts to be conservative. In fact, you usually do have to be conservative, if you want to achieve a given level of security. This allows you breathing room for unknown attacks, as well as the intricate nit-picks that fill the nooks and crannies of primitives and their underlying components. So, satisfying the threat model, and level of security, isn't always fitting it "to a T", but rather, getting something a little larger for it to allow enough prerequisite room, just to meet the assumed level of security, and some more to grow into, just in case you find yourself in worst-case scenarios or in the path of a clever adversary.


moner wrote:

can someone help me understand how password cracking or brute force works? how does a program know that a particular password that has been found is the correct one? e.g say my password was "pass", how would the computer program know that it has hit bulls eye for e.g for a pgp disk or something else...i know it might be basics for most of you but I don't know


Consider an offline dictionary attack, where the attacker has a copy of a hashed password value (i.e., MD5 or SHA-1, most likely), extracted from the database of an online login system. His dictionary consists of plaintext entries along with their corresponding hash values. During the dictionary exhaust, he attempts to locate an entry who's corresponding hash value matches that of the hashed password value extracted from the target's database. It is, essentially, a variational form of a known-plaintext attack. Raw exhaustive search is much generalized, but relies on most of the same requirements.

Author: moner PostPosted: Wed Nov 10, 2004 5:27 pm    Post subject:
    ----
AdamV wrote:

For example, on a Windows network, when you change your password, it is encrypted and only the encrypted version is stored, never the plaintext. When you log in, your password attempt is encrypted and this is compared with the stored encrypted copy.

SO, the cracking tool does the same thing - it makes up a word to try (or a set of random characters) and then encrypts this and compares with the encrypted hash which has either been taken off a server or possibly sniffed from the network.

Does that make sense?


thanks to all of you that makes good sense, but are there any further articles you would recomend?

Author: mr_brightttLocation: Omaha, Nebraska PostPosted: Sat Jul 02, 2005 6:39 pm    Post subject:
    ----
tip-i often combine passwords or random phrases that i use alot. Like all that glitters killed the cat

It is pretty random and I have used it for an account for about a year. Have had no hacks.

Author: Specialone PostPosted: Sat Aug 13, 2005 10:29 pm    Post subject:
    ----
You can also verify your password with a programm like steganos http://www.steganos.com/

Author: Hailmus PostPosted: Tue Nov 15, 2005 9:11 am    Post subject:
    ----
I use somewhat complicated passwords for many things that allow them
for example for an antivirus program one might use something like (for example) euc7-Ļ1q&Td)n( or something like that. for some people that might be hard to remember.. also if it was a passy for some encrypted folder you wouldnt want that laying around unlike a hidden passy on paper for logging in.

Here are some hints for hiding some of your passwords easily on your PC:
1) add a readme.txt to somewhere in a folder.. and copy n paste a usual readme text in there..in that text hide your password (readme's are BORING! and seldom would any attacker look there)
2) Default windows pics (or hide it in a huge photo gallery ) what you can do is open a big picture in Mspaint or some photo editing prog. and add text in a section a little off color of what you are typing it on..add your passwords here for easy lookup ..if you really want to be safe encrypt a picture folder with an easy to remember passy and then hide your hard ones here.

I for one though remember most of mine.. and even though they are hard ones..you can do it if I can.

Author: JerryHou PostPosted: Fri Dec 09, 2005 2:53 pm    Post subject:
    ----
That's a good article.Thank you !

I make a password have 15 characters,including A-Z,a-z,1-9 and dot.

Author: zhx PostPosted: Tue Dec 20, 2005 6:15 pm    Post subject:
    ----
For whatever reason, I memorize long strings of random characters easily, and for a while, after I installed a certain piece of software, I would use chunks of the serial number as passwords.

Now my favorite technique is to choose a random word and 1337-ify it one way or the other. My general procedure is as follows:

1. Pick random word (normally at least 8 chars):
accelerate
2. 1337ify!:
@cc3l3r@t3
3. If I really want to beef it up, I will discard a random character and/or replace with another random character:
@c3l3r@t3, @c#3l3@t3

(I guess this is a poor example for the forum, as @ is turned into -at-.)

Don't forget that it doesn't matter that you have a 56 character password using half the characters on your keyboard if you keep it on a sticky note on your monitor.

Author: capiLocation: Portugal PostPosted: Wed Dec 21, 2005 1:43 pm    Post subject:
    ----
zhx wrote:
(I guess this is a poor example for the forum, as @ is turned into -at-.)

No worries, I take it you mean something like this:

1. Pick random word (normally at least 8 chars):
accelerate
2. 1337ify!:
@cc3l3r@t3
3. If I really want to beef it up, I will discard a random character and/or replace with another random character:
@c3l3r@t3, @c#3l3@t3

Smile

Author: yuvarajLocation: US PostPosted: Wed Jun 21, 2006 9:07 am    Post subject: Secure Password try this
    ----
oh! yes, its said rightly that the best is alphanumberic passwords for secure login. If this type of password is too difficult to remember then have it in this type.

For example: if the password is "n1a4m3e." Just make this "n!a$m#e." (shift key for number), somewhat difficult to guess by the hackers.

just make this with the numbers or words you easily remember.

Author: the_wanderer PostPosted: Fri Apr 13, 2007 7:44 am    Post subject:
    ----
Very good and informative tutorial. But I have a couple of questions:

Let's say I want to put the first letter of each word of a favourite lyric.
Ex: smwiltbtlosavopb

Then I capitalise the 1st, 6th, 11th, 16th => SmwilTbtloSavopB

I then add some special characters at the beginning and end like
@SmwilTbtloSavopB% and some numbers @SmwilTbtloSavopB%5388
Can it be effective ? Presuming that I am good at remembering such words.

And if I wanted to use an ASCII character, will I have to type at the password prompt the same sequence for the required character ? I never tried it Embarassed

Thanks !

Author: mcse_696 PostPosted: Sun Apr 29, 2007 1:25 am    Post subject: syskey extra secure
    ----
You can use the (SysKey) utility to additionally secure the SAM database by moving the SAM database encryption key off the Windows-based computer. The (SysKey) utility can also be used to configure a start-up password that must be entered to decrypt the system key so that Windows can access the SAM database. This article describes how to use the SysKey utility to secure the Windows SAM database.
1. At a command prompt, type (syskey), and then press ENTER.
2. In the Securing the Windows Account Database dialog box, note that the Encryption Enabled option is selected and is the only option available. When this option is selected, Windows will always encrypt the SAM database.
3. Click Update.
4. Click Password Startup if you want to require a password to start Windows. Use a complex password that contains a combination of upper case and lower case letters, numbers, and symbols. The startup password must be at least 12 characters long and can be up to 128 characters long.

Note If you must remotely restart a computer that requires a password (if you use the Password Startup option), a person must be at the local console during the restart. Use this option only if a trusted security administrator will be available to type the Startup password.
5. Click System Generated Password if you do not want to require a startup password.

Select either of the following options:ē Click Store Startup Key on Floppy Disk to store the system startup password on a floppy disk. This requires that someone insert the floppy disk to start the operating system.
ē Click Store Startup Key Locally to store the encryption key on the hard disk of the local computer. This is the default option.
Click OK two times to complete the procedure.

Remove the SAM encryption key from the local hard disk by using the Store Startup Key on Floppy Disk option for optimum security. This provides the highest level of protection for the SAM database.

Always create a back-up floppy disk if you use the Store Startup Key on Floppy Disk option. You can restart the system remotely if someone is available to insert the floppy disk into the computer when it restarts.

Author: Madgeki PostPosted: Mon Jan 17, 2011 7:35 pm    Post subject: hi! moner Lurker
    ----
yes it does make sense, brilliant!



Networking/Security Forums -> Physical Security and Social Engineering


output generated using printer-friendly topic mod, All times are GMT + 2 Hours

Page 1 of 1

Powered by phpBB 2.0.x © 2001 phpBB Group