echo "Word: ";
$st = trim(fgets(STDIN));;
$len = strlen( $st );
echo "Scrambling Number: ";
$rot = trim(fgets(STDIN));
if( $rot=='' )die('');

so that even the site name is not stored in the history file.

if( $argc!=2 )die( "usage conv " );
$st = $argv[1];
$len = strlen( $argv[1] );
echo "Scrambling Number: ";
$rot = trim(fgets(STDIN));
if( $rot=='' )die('');

Because otherwise if the scrambling number is taken from the command line it will be stored in the history file in linux systems.

<?php

if( $argc!=3 )die( "usage conv <file> <rot1>" );

$st = $argv[1];

$len = strlen( $argv[1] );

$rot = $argv[2];

if( !preg_match( "/^[0-9]+$/", $rot ) )die( 'rot must be a number' );

$extra = strlen( $rot );

$vals = array();

for( $i=0;$i<$extra;$i++ ){

	$val = ord($rot[$i])-48;

	$vals[$i] = $i%2 ? -$val : $val;

}

function rot( $ch, $inc )

{

	$ch = ord( $ch );

	if( $ch>=97 && $ch<123 ){

		$ch -= 97;

		$ch += $inc;

		if( $ch>=26 ){

			$ch %= 26;

		}else if( $ch<0 ){

			$ch += 26;

		}

		return chr( $ch+97 );

	}

	return chr( $ch );

}

for( $i=0;$i<$len;$i++ ){

	$val = $vals[$i%$extra];

	echo rot( substr( $st, $i, 1 ), $val );

}

?>you use it like:

php word.php word scramblingnumber

suppose the site is mail.yahoo.com I type

php word.php mailyahooshankarcom 298347932384

I use the same scrambling number for every site simple to remember yet no one can guess it.
Also the password or scrambling number is not stored anywhere.
What do you think?

All the security in the world is useless if people don't pick secure passwords so it's good to see lots of discussion about this topic of late.

GPUs can be used in parallel to attempt to crack passwords very quickly and inexpensively, but a long, random password is not the lowest barrier to entry (yet).

For accounts you care about:

1. Use a password safe. This is basic, entry-level security.
   
2. Don't use it anywhere but on your own computer. It takes 12 seconds for a random person to install a hardware keylogger on a public computer, and you really can't know what spyware the owner of the computer has set up (e.g. archive the contents of every USB stick inserted).
   
3. Set up as much security on your computer as your expertise and hardware will allow. This is difficult, and still an area of active research. Full-disk encryption is a start.

Cheers,

http://chinesedemocracyforum.com

Then enter it twice, one time regular one time holding shift key. But I also hit the letter below the number: 1q, 2w, 3e etc.

So the date: 19970725 becomes

1q9o9o7u0p7u2w5t!Q(O(O&U)P&U@W%T

lower case, upper case, digits, sp. char.
easy to remember, very strong.

Also you can write down your passwords without compromising security.

Bank = Birthday
G-Mail = Anniversay
Amazon = Mom's Birthday

My question is...
Rather than asking if the actual implementation of passwordchart.com is sound, would it be just as safe to take two easy to remember passphrases, one to seed a PSNG and the other to map to the output as opposed to choose a random hard-to-remember password?

Would you trust this method to one of your friends as a alternative to have strong passwords that are easy to remember?

For Password Safe and other password storage programs, for more security, I'd hand-encrypt the passwords as you enter them. You'll have to decrypt them as you use them (thus barring automatic use or copy-and-paste), and if you need the program as your personal memory jog you'll probably need a hand-encryption method that's also memorable even for rarely-used passwords, so you'll probably want to come up with a method that's relatively easy to crack, especially if someone cracks one of your passwords and thus sees your re-encryption method. But this is still better than risking someone cracking your storage software on a multicomputer setup, because the cracker is forced into a second step, if it occurs to them, which it may when their first results fail to reveal your secret contents.

Length-limiting of a password is sometimes unannounced. An interface sometimes lets you enter any length you like (at least where I haven't hit a limit), then the program ignores whatever is past some length limit without telling you. This leads to false security, at least in part. This is somewhat like when people are asked for part of some secret number and they give the part out because they're not giving the whole thing away, because they don't realize that the rest of the number can be determined by other means. So the advice about not telling anyone your password, including a password-protected-site owner, applies to parts of passwords, too.

Likewise, case is sometimes ignored or converted (same result), again allowing a false sense of security.

Linux does not always have separate partitions. That varies by distro, unless you go to the trouble of setting up that way despite the defaults in your distro, and setting that up may entail more than partitioning your hard drive yourself, because you may have to convince the installer to put some Linux files on different partitions and then make some partition/s invisible to users, unless you can figure out how to do that yourself. Friendlier distros, in my observation, are less secure and less likely to have second partitions and unlikely to offer an option of second-partitioning explicitly. I've seen single-partitioning on a distro with SELinux on, so SELinux is not correlated with separate partitioning, which would still be useful. I think the original Linux has for many years included multiple partitioning but that some distribution programmers disable it in order to simplify users' installation experiences or to ease coexistence and multibooting with other OSes.

I create a random password or, more often due to lack of time and a spreadsheet when I need a new password (away from home), a mental attempt at a password (remembering that humans have had to try to impose order just to enhance survival since cavedwelling ages and so I have to compensatorily impose disorder from character to character). I don't worry about long-term memorability, because with use the human tendency to find order will tend to yield mnemonics that aren't necessarily absurd.

The danger of someone hacking into your email account (etc.) is that they can send emails on your behalf without leaving a copy for you. You may never find out; or someone may reply with unexplained anger at you, for example, or bill you for something you obviously did, since your email authorized it, as far as anyone can see. Likewise for online accounts, forums, etc. I had one vendor shut my account down because they were sending passwords unencrypted over the Internet; although they claimed they couldn't close the account, their terms said I'd be liable for whatever was bought on it. I persuaded them to shut it down. On a forum, someone can post libels on your behalf and you get the lawsuit. I'm not sure an employer wants to hire someone who explains bad actions by saying their password was stolen. Recommendation: Use secure passwords.

--
Nick

Encoding variations (UTF-n, ISO-n, & perhaps others) leave me wondering if the same key cap or keystroke combination can be mapped to more than one bit sequence or if multiple keystroke combinations can be mapped to one bit sequence. I seem to have run into discussions about Linux facing this issue. If so, then encryption software that converts a password to a key should accept multiple passwords for the same key or generate multiple keys from the same password. As this is sometimes normalized by geography but encryption/decryption is performed across borders, conversion has to be locale-independent and thus more or less encoding-independent, yet also keyboard-layout-independent (layouts vary by nation, assuming that Dvorak/qwerty doesn't matter). As I recall, upper ASCII (decimal 128-255 or (hex) 0x80-0xFF) differs markedly between Win and Mac, at least for old Mac like System 6, yet passwords would normally be shared between sender and recipient humans only by stating key cap sequences or key cap combination sequences, especially relevant where user machines are on mixed-OS networks using unknown-OS servers for these functions.

If all encodings agree only on ASCII in which the most significant bit (MSB) is masked, perhaps the most secure passwords should be limited to the lower 7 bits minus control characters (i.e., limited to decimal 32-126 or 0x20-0x7E, constituting alphanumerics without diacriticals and !"#$%&'()*+,-./:;?@[\]^_`{|}~ (in ASCII order) (I'm trusting the software where I'm posting this correctly represents those characters but they can be checked in Win's Character Map set to a common body text font). One writer about Linux filenames argued for using only POSIX-compliant characters for filenames: alphanumerics without diacriticals and - and _ only; perhaps that should apply to passwords, too, if encoding is a problem, but definitely not if encoding is not a problem.

Is any password/key conversion system open-sourced and is that open source conversion system in use in any accepted encryption program? Alternatively, are conversion methods independently analyzed? Or am I wrong that encryption may be compromised by using other than lower 7-bit ASCII for the password because of the conversion to a key?

--
Nick

One writer seems to say that a password character correlates with 4 bits of the key. Is that so? For the following, I generally assume 8 bits per character.

Given that one creates a key when encrypting by creating a password or passphrase, doesn't that mean that, for example, a 128-bit key requires a 16-byte or 16-character password? If so, wouldn't diverging from that ratio compromise security? Since the ratio differs on machines using other than 8-bit bytes (e.g., 9-bit bytes), what happens to security if the key length is not an integral multiple of the byte length? And does encryption software have anything to do with byte length?

For a too-short password, 3 choices face the encryption program: (1) Shorten its key length to accommodate the received password. That cuts security inherent in encryption. (2) Pad the password to the key's length by assigning a character string of its choosing equal to the length deficit. The string would have to be either invariant or generated from the password, but always the same whenever the password was the same as another password, as well as always the same for all copies of the program and all compatible versions and all compatible software (e.g., I don't recall hearing that one must decrypt 3DES with the same brand of program that encrypted the file). It wouldn't take long for a cracker to figure this method out. (3) A combination or alternation of the above depending on the password. Combining or alternating would have to be predictable, or decryption would sometimes fail.

For a too-long password, the program's choices may be less problematic. (1) It can lengthen its key length. Export restrictions limit this option. If the export limit is 56 bits, that's maybe 7 bytes, and discarding password characters past 7 weakens security. (2) It can discard or ignore part of the password per a consistent scheme. Predictable. Thus, the user's sense of security from having a long passphrase would be excessive. People induced through social engineering to reveal part of their password (e.g., at work) might be revealing the only part that matters. (In one office, I was given my Windows password by my supervisor and not allowed to change it; I found a way to monitor his frequent entries into my computer, but I don't know what he was doing there.) Socially engineered revelations are not always due to individual laxity; an institution may impose teamwork obligations that require cooperation. (3) Again, it can combine or alternate protocols, but only predictably.

This also could vary according to the encryption method built in, but if it doesn't (and if conversion is not part of the encryption method) any weakness here would be multiplied. E.g., if an encryptor program uses one method to convert a password to a key and offers two encryption algorithms, that conversion method would apply to any file regardless of which encryption method was used, and thus the conversion method would have to be shared in common with all software that is encryption-method-compatible for either encryption algorithm.

-- Nick

When I'm setting up accounts in the fall, I run a program that analyzes a block of text, creates a chain what letters can follow what letters. Then it does random passes through this. This gives me mostly pronouceable but not very vulnerable to dictionary attacks. Add a couple of upper cases or a punctuation mark, and it's done. Typical results:
fliPPleKnip, GarfkNorkit, zurfendlip!!

windows/linux pagefile : I don't employ the pagefile at all. If you have enough RAM, then you don't need the pagefile. Although, I am not sure if someone can scavenge from your RAM ? does POST zero it each time ?

BR,
~A

But when do we come up with a way to fix the original cause of the problem? That is, finding and punishing the criminals causing this problem. How can we (or the Big People at Microsoft, IBM, the ISPs, Apple, Congress, Federal Agencies, the various software/system organizations and geniuses, etc., etc.) track down and prosecute these criminals and vandals? Or at least come up with a reasonable software/hardware solution to prevent these attacks within our PCs?

I know many of these attacks come from outside the United States and that prosecuting those criminals and disturbed kooks becomes harder. Yes, I know these attacks are masked by spoofed IDs, anonymous and hijacked IPAs, etc. And that there are many criminals, vandals, kooks, and jerks committing these crimes.

But it is hard for me to believe that:

First- these criminals cannot be traced, arrested, prosecuted, and punished. Even if this means that operating systems, the internet, local and international laws, and whatever, be modified to accomplish this.

Second- our PCs cannot be protected from these attacks. Why can't operating systems, the internet, or whatever, be modified to accomplish this? And at no additional or modest cost?

It is time to stop treating the symptoms and to now fix the root of the problem. We need to prevent the creation of cancer.

I've always taken a sentence or a few lyrics to a song and then used the first letter of each word as my password, replacing letters with numbers where possible.

Example:

for those about to rock we salute you

becomes

fta2rwsy

This makes a rather obscure password very easy to remember. Of course the longer the better but this is just an example.

As I read, one possible weakness in html-forms secured by SSL (normally 128 Bit) could be an attacker listening to always the same input sequence (same plaintext password) in the POST data.

My suggestion: Increasing the (first time empty) input field by some md5-noise (depending on a random number) before user input. Ok, thats not a nice looking input field ;-) Better idea?
At the end, for computing the POST data is read and the noise only had to be cutted.

Bye, Axel

reading this site I finally realized that strong crypto is really hard work to do _right_. You have to look at the side of the user input and the side of encryption algo. You have to fight against rainbow tables and cracking algos. Ok, I learned and here is my suggestion:

1. User input

Easy enough to remember but cryptical and long (12-20), trivial things (a1a1a1) not allowed;
i.e. parts of names of persons (Tom Sawyer, Elisabeth Taylor to password 'ToSawyTayEli' = 12 parts) and in addition a digit.

Directly depending on this digit internally a part of the password is copied, the string md5'ed (or something else) and inserted within the inner part of the password. Now you have a longer password i.e. with 44 parts (or more), too long for r.t. or other cracking prog.

I assume that even if the 'inserting' part of the program code is known, the cracking program doesn't work because the minimum 12 parts password and the additional possible variations caused by the digit would bloat the number of required loops enormously.

2. Crypto Algos (Hashes)

In the first step encrypting the 44 parts with i.e. ripemd256 to get an encrypted 64 parts value (now no zero values and so on to weak the encryption). In the second step this value encrypted with i.e. sha256.

Is this the right way to sleep well?

Bye, Axel

PS: I read on this site about tries per second (wow). I assume with the right (big!) hard- and software it is possible to handle the work parallel (one prog opened many times in different caches) and so there is no real limitation by the attacked prog, is that right?

There are plenty out there, both traditional, and online:
http://passpack.wordpress.com/2007/01/29/...

Cheers,
Tara

Step 1. Open any text file of more than 1kb in a text editor.

Step 2. Using PGP or GPG, encrypt the current window of text with whatever passphrase you want.

Step 3. Delete the PGP header and first 2 or 3 rows of text, and the PGP footer and last 2 or 3 rows of text.

Step 4. The result is several rows of seemingly garbled "junk" text. The text has a character-space of 64. (all 10 digits, 26 upper-case, 26 lower-case, "/" and "+".) Using the formula X^L, where X=character-space and L=length, the total possible passphrases is 64^64, or 3.9402006196394479212279040100144e+115.

Any row can be used as a password. Additionally, you can number these for reference when naming the encrypted file.

The drawback is that you must store this list. However, smart people will encrypt the list itself using PGP or GPG with quite a long passphrase. I use any one of several memorized passwords of 32 bytes each.

The final drawback is that PGP disables the paste hotkey; but GPG does not.

Any thoughts?

It depends what service you are using. As AOL shortens passwords to 8 characters it could easily be found by a dictionary attack. Same for passwords which first 8 characters are in a dic.

Neither password will ever be broken by the current -- and forseeable future -- generations of password guessers.

"Which passphrase below will likely be broken first in real life situation by government agencies?

1. E5&crW9C@8#x (12 random characters)

2. aaaaaaaaaabbbbbbbbbbccccccccccdddddddddd (4x10 = 40 characters)"

Can anyone give a comment on that now? How secure is such a "long password strategy"? Similarly, I've seen some people advocate using a long sentence as password. A related strategy would be to repeat a simple word multiple times and then add some other stuff. For example: "soccersoccersoccersoccersoccer$$soccer". That's an easily memorized password: 5 soccer, 2 dollars, 1 soccer. But how secure is it?

http://www.avertlabs.com/research/blog/?p=47

wow! this is loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong!!!!

"A follow-up on what Erdrick asked: I use a hot key to enable my keyboard's second set of fonts (Czech language) and throw them into the mix, giving things like FuřřýCátIšBa�?k for example. Does this actually improve things at all?"

It depends upon which Unicode or ASCII characters ranging from 128 to 255 are used.

I am only going to look at this regarding Windows logon passwords; banks and websites will probably be different. Here is a Microsoft article about using Unicode characters in passwords:

http://www.microsoft.com/canada/smallbiz/sgc/...

Microsoft's advice is that some Unicode characters can be used to improve the password strength but watch out - some Unicode characters are automatically converted to standard alphanumeric format when the password is stored. Have a look at the table headed "Recommended ALT Code to Use for ALT Key Combinations". It seems to me that a half decent password with some Unicode characters thrown in would really screw up attempts at offline cracking.

P.S. I keep intending to load Password Safe and try it but haven't yet. Does anybody know if Password Safe will handle Unicode passord characters as recommended my Microsoft?

Why are we "experts" in quotes? Do we really not have expertise?

In any case, of course you're right. Lots of programs have this countermeasure. It works great in systems where only on-line attacks are possible, and are why four-digit PINs are secure in some situations.

The threat scenario I wrote about was an off-line password guessing attack, because that's the more powerful attack.

There are delay schemes that work here, too, and it's exactly what I am describing in the seventh paragraph of the essay. Programs like PGP and PasswordSafe have very long password-to-key conversion routines, and that greatly slows down password guessing attacks.

There's a trade-off between how long the user is willing to wait, though, so we don't use minute-long conversion routines; 100ms is generally considered to be a good length.

And, of course, these defenses don't make password guessing attacks impossible, just slower. PRTK still breaks easy-to-guess passwords used in these programs.

I respect and support your line of reasoning here, TomD, but want to remind you that many hack attacks occur 'offline' and so are not constrained by an interface like Windows' Logon, or AOL's Sign-On, or WinZip, etc. Rather, the hacker has grabbed a copy of your system's hash file (e.g. SAM, NT, etc.) and may bash on it freely without restrictions. All the attacker need do in many cases is (trivially) look up and compare your unknown password's hash (e.g. MD5) against a very long list of hashes for known strings (e.g. rainbow tables). Worse, if the attacker were armed with knowledge of the hashing algorithm of your particular app (WinZip) or possessed a crippled version of the app you propose (his might omit the delays, for instance), he'd still get pretty far. Likewise, the attacker always has the easier option(s): sitting outside your home/office sniffing wireless traffic (until you type your password!); deploying a keylogger on your PC; videotaping your sessions; socially engineering a password reset (by calling your ISP or IT Dept.); blackmailing your vendor/wife/boss, etc.
Back to your initial assertion (with which I still AGREE), why not also have multiple passwords instead of just one? For example, GMail's welcome screen could challenge you (in a way similar to banks now do) with three password fields, each marked with a predetermined graphic ("guitar", "ostrich", "tower") in random order. Your job at login would be to enter your (three) passwords in the correct order. Sure, it wouldn't prevent keyloggers or screen scrapers from snagging your info, but it'd go a long way toward stymieing brute force attacks.