• RSS
  • Twitter
  • FaceBook

Security Forums

Log in

FAQ | Search | Usergroups | Profile | Register | RSS | Posting Guidelines | Recent Posts

[Tutorial] - How to Create a Secure Password

Users browsing this topic:0 Security Fans, 0 Stealth Security Fans
Registered Security Fans: None
Goto page 1, 2, 3, 4  Next
Post new topic   Reply to topic   Printer-friendly version    Networking/Security Forums Index -> Physical Security and Social Engineering

View previous topic :: View next topic  
Author Message
JustinT
Trusted SF Member
Trusted SF Member


Joined: 17 Apr 2003
Posts: 16777215
Location: Asheville, NC, US / Uberlândia, MG, Brazil

Offline

PostPosted: Sun Aug 15, 2004 4:25 am    Post subject: Passwords, passphrases, and pseudo-randomness. Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website
Security Hobbit
Just Arrived
Just Arrived


Joined: 14 Jul 2004
Posts: 0


Offline

PostPosted: Mon Aug 16, 2004 1:01 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
NeonWizard
Just Arrived
Just Arrived


Joined: 06 Aug 2004
Posts: 0
Location: Vancouver, Canada

Offline

PostPosted: Tue Aug 17, 2004 3:19 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
JustinT
Trusted SF Member
Trusted SF Member


Joined: 17 Apr 2003
Posts: 16777215
Location: Asheville, NC, US / Uberlândia, MG, Brazil

Offline

PostPosted: Wed Aug 18, 2004 10:59 am    Post subject: Opinions. Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website
Security Hobbit
Just Arrived
Just Arrived


Joined: 14 Jul 2004
Posts: 0


Offline

PostPosted: Wed Aug 18, 2004 8:02 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
capi
SF Senior Mod
SF Senior Mod


Joined: 21 Sep 2003
Posts: 16777097
Location: Portugal

Offline

PostPosted: Thu Aug 19, 2004 11:54 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
NeonWizard
Just Arrived
Just Arrived


Joined: 06 Aug 2004
Posts: 0
Location: Vancouver, Canada

Offline

PostPosted: Fri Aug 20, 2004 12:02 am    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message Visit poster's website MSN Messenger
Security Hobbit
Just Arrived
Just Arrived


Joined: 14 Jul 2004
Posts: 0


Offline

PostPosted: Fri Aug 20, 2004 8:48 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
0x54
Just Arrived
Just Arrived


Joined: 01 Aug 2004
Posts: 0


Offline

PostPosted: Fri Aug 20, 2004 11:53 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
JustinT
Trusted SF Member
Trusted SF Member


Joined: 17 Apr 2003
Posts: 16777215
Location: Asheville, NC, US / Uberlândia, MG, Brazil

Offline

PostPosted: Fri Aug 20, 2004 12:48 pm    Post subject: More thought. Reply with quote

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.
Back to top
View user's profile Send private message Visit poster's website
capi
SF Senior Mod
SF Senior Mod


Joined: 21 Sep 2003
Posts: 16777097
Location: Portugal

Offline

PostPosted: Fri Aug 20, 2004 8:13 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
Greatis
Just Arrived
Just Arrived


Joined: 20 Aug 2004
Posts: 0
Location: Montego Bay, Jamaica

Offline

PostPosted: Tue Aug 24, 2004 3:29 pm    Post subject: Reply with quote

Very informative tutorial and placed in the right section too.
Back to top
View user's profile Send private message Visit poster's website AIM Address MSN Messenger
AdamV
SF Mod
SF Mod


Joined: 06 Oct 2004
Posts: 24
Location: Leeds, UK

Offline

PostPosted: Wed Oct 06, 2004 5:34 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message Visit poster's website
alpinelegend
Just Arrived
Just Arrived


Joined: 22 Jun 2004
Posts: 3


Offline

PostPosted: Wed Oct 06, 2004 6:03 pm    Post subject: Reply with quote

I think i better change my password now Embarassed
Back to top
View user's profile Send private message
mightB
Just Arrived
Just Arrived


Joined: 10 Sep 2004
Posts: 0


Offline

PostPosted: Thu Oct 14, 2004 3:58 pm    Post subject: Reply with quote

is not more secure to have a password that is word from another language, so that it wont be prone to [English] dictionary attack?
Back to top
View user's profile Send private message
Karina
Just Arrived
Just Arrived


Joined: 02 Jun 2004
Posts: 0


Offline

PostPosted: Thu Oct 14, 2004 6:14 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Display posts from previous:   

Post new topic   Reply to topic   Printer-friendly version    Networking/Security Forums Index -> Physical Security and Social Engineering All times are GMT + 2 Hours
Goto page 1, 2, 3, 4  Next
Page 1 of 4


 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Community Area

Log in | Register