Years ago it used to be the case that Unix passwords were limited to 8 characters, or that if you made the password longer than 8 characters the extra wouldn't make any difference.
Is that still the case on most modern Unix/Linux systems?
If so, around when did longer passwords become possible on most systems?
Is there an easy way to tell if a given system supports longer passwords and if so, what the effective maximum (if any) would be?
I've done some web searching on this topic and couldn't really find anything definitive; much of what came up was from the early 2000s when I think the 8 character limit was still common (or common enough to warrant sticking to that limit).
Although the original DES-based algorithm only used the first 8 characters of the password, Linux, Solaris, and other newer systems now additionally support other password hash algorithms such as MD5 which do not have this limit. Sometimes it is necessary to continue using the old algorithm if your network contains older systems and if NIS is used. You can tell that the old DES-based algorithm is still being used if the system will log you in when you enter only the first 8 characters of your >8-character password.
Because it is a hash algorithm, MD5 does not have an intrinsic limit. However various interfaces do generally impose some limit of at least 72 characters.
Although originally the encrypted password was stored in a world-readable file (/etc/passwd), it is now usually stored in a separate shadow database (e.g. /etc/shadow) which is only readable by root. Therefore, the strength of the algorithm is no longer as important as it once was. However if MD5 is inadequate, Blowfish or SHA can be used instead on some systems. And Solaris supports pluggable password encryption modules, allowing you to use any crazy scheme. Of course if you are using LDAP or some other shared user database then you will need to select an algorithm that is supported on all of your systems.
In glibc2 (any modern Linux distribution) the password encryption function can use MD5/SHA-xxx (provoked by a magic salt prefix) which then treats as significant all the input characters (see man 3 crypt). For a simple test on your system, you could try something like:
#!/bin/perl -w
my $oldsalt = '##';
my $md5salt = '$1$##$';
print crypt("12345678", $oldsalt) . "\n";
print crypt("123456789", $oldsalt) . "\n";
print crypt("12345678", $md5salt) . "\n";
print crypt("12345678extend-this-as-long-as-you-like-0", $md5salt) . "\n";
print crypt("12345678extend-this-as-long-as-you-like-1", $md5salt) . "\n";
(which on my system gives)
##nDzfhV1wWVg
##nDzfhV1wWVg
$1$##$PrkF53HP.ZP4NXNyBr/kF.
$1$##$4fnlt5pOxTblqQm3M1HK10
$1$##$D3J3hluAY8pf2.AssyXzn0
Other *ix variants support similar - e.g. crypt(3) since at least Solaris 10.
However, it's a non-standard extension - POSIX does not define it.
Not for Linux. It's only 8 if you disable MD5 Hashing.
http://www.redhat.com/docs/manuals/linux/RHL-8.0-Manual/security-guide/s1-wstation-pass.html
You can administer policies enforcing longer and more complex passwords as well.
The full lengths are discussed here:
http://www.ratliff.net/blog/2007/09/20/password-length/
Are you asking about the crypt algorithm?
http://linux.die.net/man/3/crypt
"By taking the lowest 7 bits of each of the first eight characters of the key..."
"The glibc2 version of this function has the following additional features. ... The entire key is significant here (instead of only the first 8 bytes)."
Here's a hint as to how long ago this change happened.
Glibc 2 HOWTO
Eric Green, ejg3#cornell.edu
v1.6, 22 June 1998
You will find this article of interest. There is something called PAM (Password Authentication Module) which runs your password through a series of modules (configured in /etc/pam.d/passwd or /etc/pam.conf) to determine whether the password is valid or not.
I think around the time when actual passwords were moved from /etc/passwd to shadow, on Linux . I am guessing around 2000, Red Hat 6.x had long passwords IIRC. Around 2000 there were still a lot of old SUN, and they had password and username limits.
Related
I am writing a shell script that will be deployed to multiple machines and connect to a central server. When connecting, the script should identify the machine it is running on. (This is used to implement some rudimentary locking but that's not important for the question.)
I know that I could use the host-name, as reported by hostname -f, to identify the machine. But many personal devices have far from unique host-names, such as my-laptop or workstation so I'm wary of using this.
I might be able to add entropy by hashing the host-name together with some other host-specific information that will not change.
echo $(hostname -f) $(uname -snmpio) | md5sum
But the added entropy is very low. I'm having a hard time thinking of other system properties that can be hashed and are guaranteed not to change. (For example, I don't want to add any properties of the file system or other system configuration1 because it might legitimately change at any time.)
Finally, I thought about generating a random string the first time the script is run and store it in some configuration file. This wold be extremely likely to be unique and guaranteed not to change. But if possible, I'd prefer not having to manage persistent state.
Ideally, there would exist a utility to obtain a deterministic non-volatile UUID for the local system (like blkid for block-devices). It is not required that the UUIDs be hard to forge. This is not an authentication mechanism and I'm trusting all parties that run the script.
Are there any superior options I have overlooked?
1 Technically, the host-name is a system configuration, too. But if we change it, we expect the system to no longer be identified as the one it was before.
How to Generate Version 4 UUIDs
The easiest way to generate a unique identifier is to use a UUID. The most common type of UUID for this purpose is UUID v4, which is generally the correct choice unless you have some specific circumstances (e.g. namespacing requirements or poor sources of entropy) that would lead you to using one of the other UUID types.
You can use uuidgen on Linux, which can be found in the "uuid-runtime" package on Debian-based systems. The uuidgen tool is also installed by default OS X, should you need it. On Linux, the tool relies on libuuid and /dev/random to generate Version 4 UUIDs. If a high-quality random number generator isn't available, uuidgen will fall back on Version 1 time-based UUIDs.
UUIDGEN(1) says:
There are two types of UUIDs which uuidgen can generate: time-based UUIDs and random-based UUIDs. By default uuidgen will generate a random-based UUID if a high-quality random number generator is present. Otherwise, it will choose a time-based UUID. It is possible to force the generation of one of these two UUID types by using the -r or -t options.
As a general rule, if you're able to do so you should definitely stick with Version 4 as Version 1 has known security risks and limitations to its uniqueness properties. However, specific use cases may vary.
In the interest of providing options, you could use the RSA fingerprint of the localhost. Your machines most likely have all the components necessary already configured.
hostkey=$(ssh-keygen -l -f /path/to/host_key.pub)
The output will contain spaces and whatnot, but you could parse those out if it is a problem. The host key is usually in /etc/ssh/ssh_host_* but may depend on the distribution of linux.
For a file repository, I need to select a hashing algorithm that will reasonably ensure the integrity of files.
I need an algorithm that anyone (with a bit of effort) would be able to easily use to verify the integrity given the hash. In short, the file may be transferred to the user, along with a hash, and they must be able to verify that the hash comes from the file.
My first choice would be MD5 because there seems to be widely available utilities to verify MD5 hashes, but I'm concerned with the MD5 algorithm being cryptographically broken (ref Wikipedia/US-CERT: http://en.wikipedia.org/wiki/MD5)
My second choice would be a SHA-2 algorithm, but I'm concerned about availability of utilities that could easily verify the hash. Most examples I've found show program code to evaluate a hash, but I've found few, if any, utilities that are pre-built (asking users to build their own utility is beyond the 'easily' scope)
What other options are available for generating and evaluating a file hash, or are these two the options that are best?
Provide both/multiple, and let the user decide which they verify against. Or if they are really cautious, they can verify against both/all.
Have seen download sites use this approach. One site recommended the most secure, but offered others like md5 as fallback. It also provided links to tools. Can't remember specific site I'm afraid.
Since you've been able to find a few file-checkers, why not link to them as a recommendation? That way your users have at least one tool they can use. They don't need several dozen different filechecking utilities, they need just one which works for the algo you chose to use.
Tools you could link to:
Windows: http://securityxploded.com/download-hash-verifier.php
Mac OS X: http://www.macupdate.com/app/mac/31781/checksum
sha256sum, a program a part of the coreutils package on linux will generate checksums for the listed files. The format of the checksum output is the same as that of the md5sum program (but using SHA-256 hashing instead of MD5 of course), which has been widely used for years. You didn't list any target platforms but a quick googling shows there are Windows ports of the command line program.
If you need to generate large numbers of checksums you can use md5deep, which includes support for other hashes as well, including SHA-256.
http://md5deep.sourceforge.net/
I haven't tried this but from the screenshots it looks pretty neat integrating into OSX and Windows Explorer: http://implbits.com/HashTab.aspx
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 12 years ago.
Improve this question
these char can be entered by keyboard by pressing with the combination of ALT and ASCII of char
I think these ☺ ☻ ♥ ♦ ♣ char can't be easily cracked by brute force attack.
It would depend a bunch of things, including what program is accepting the password, where and how are they storing it, what platforms the server and client are running on, and likely others. You may be able to log in using this password from a Windows client but not Unix (or vice versa). If this is a web app, it might work on one browser but not another. Or it might work differently on an English machine vs. a Japanese machine.
I would recommend against this. It's easy enough to come up with secure 7-bit ASCII passwords that going down this road isn't really necessary.
If the question is "can I use these," then the answer is "maybe." You will need to test them thoroughly to make sure that your application(s) support extended ASCII characters in passwords. If you use various operating systems or mixed-language systems, it's somewhat less likely that they'll be compatible because you start getting into different issues with encodings. There are many versions of the so-called extended ASCII set and they can be represented very differently.
If the question is "are these more secure," then the answer is "not really." Sure, increasing the number of characters that can potentially be included in a password increases its entropy value and increases the amount of time it would take for password-cracking software to crack the password. However, in practice, it's relatively unlikely that you'll see much difference by adding 5 or 6 extra characters. You can get a sufficient level of security with the password complexity requirements that are already well-supported, and tactics like increasing the minimum length of your password (perhaps to something like a pass phrase, rather than a simple word) will make cracking much more difficult than a few additional characters.
Also see the documentation for passwords in Windows Server:
An example of a strong password is
J*p2leO4>F.
A password can meet most of the
criteria of a strong password but
still be rather weak. For example,
Hello2U! is a relatively weak password
even though it meets most of the
criteria for a strong password and
also meets the complexity requirements
of password policy. H!elZl2o is a
strong password because the dictionary
word is interspersed with symbols,
numbers, and other letters. It is
important to educate users about the
benefits of using strong passwords and
to teach them how to create passwords
that are actually strong.
You can create passwords that contain
characters from the extended ASCII
character set. Using extended ASCII
characters increases the number of
characters that you can choose when
you create a password. As a result, it
might take more time for
password-cracking software to crack
passwords that contain these extended
ASCII characters than it does to crack
other passwords. Before using extended
ASCII characters in your password,
test them thoroughly to make sure that
passwords containing extended ASCII
characters are compatible with the
applications that your organization
uses. Be especially cautious about
using extended ASCII characters in
passwords if your organization uses
several different operating systems.
You can find extended ASCII characters
in Character Map. Some extended ASCII
characters should not be used in
passwords. Do not use a character if a
keystroke is not defined for it in the
lower-right corner of the Character
Map dialog box. For more information
about how to use Character Map, see
Using Character Map.
Examples of passwords that contain
characters from the extended ASCII
character set are kUµ!¶0o and
Wf©$0k#»g¤5ªrd.
OK, not even close to a programming question, but I'll answer it anyway.
The policy for what is and is not allowable in a password is decided by the individual application/website etc.
So long as the characters are valid input for a password, they can be brute-forced just as easily as any other character. A short password with strange characters is still many times weaker than a longer password made from alphanumeric characters.
When going through registration, a lot of sites will disallow the use of symbols in passwords. This drives me up the wall from a usability perspective since I include multiple symbols in all my passwords, and as a programmer that deals with web authentication from time to time, I can't figure out why it wouldn't be allowed. Am I missing something? Are they worried about SQL injection? Don't want to deal with escaping characters? Or is there something with non-Latin-alphabet characters that can mess things up?
Similar question, about sites that restrict length here.
Laziness, 2. Using legacy systems that don't support those characters for auth
They are morons
They are almost certainly storing the plain text password somehwere (see 1)
They aren't in the US: In Europe, you have a different keyboard every few miles. Good luck finding your special character on an Italian keyboard. Or a Greek one. Or Turkish.
The only keys which are probably there are the alphanumeric keys and most people will be able to find their way around them, even if a couple of the keys will be swapped (Y and Z, for example).
Lastly, people are notoriously bad at remembering passwords. Forcing them to use "honey" instead of "jh(/&DFA93475" greatly reduces the rate of calls for support ("I can't remember my password...")
If it's a web app, the developers were not really able to make sure that umlauts survive the transfer from the form to their backend. It would be great if all browser would simply send UTF-8 but most backends can't handle UTF-8 without some careful tuning, either.
It probably means they're lazy or not very smart. If you only store a hash, you won't have to worry about character sets, injections, or space. Pretty much what was explained in that other question you gave.
Our system once had to work together with 3rd party hardware which was operated through touchscreen. Their on-screen errr.... 'keyboard', surely didn't had a non-alphanumeric characters, therefore - we ran into quite serious trouble with passwords - clients had to change them.
Legacy Systems Support
I can't say if it is true for many websites, but in many antiquated network environments that use radius or another form of centralized authentication, often you have to restrict your passwords to the lowest common denominator for all of the disparate systems that you are supporting. So if you are supporting password authentication for a poorly written legacy application that has problems with non-ascii characters and that server piggy backs onto the central authentication server, you are forced to limit all of the other servers to the same password restrictions.
Poor Input Validation and Lack of Password Hashing / Encryption
The applications could have had SQL injection issues in the past and over-zealous programmers just disabled all not ascii rather than address the fundamental flaws in their design.
Unneeded Simplification
The developers may want to minimize issues with binary data petering into the password store and are over-zealous in their data validation. Honestly, I think this is the most likely scenario. The programmers may have already taken an ascii-only approach to usernames and just extended the same line of thinking to passwords.
Bad programming, and the fact they're storing it in clear text, I'm sure.
One possible reason: the site's UI is designed by a marketing type or a non-technical product manager. Someone who doesn't understand combinatorics and thinks they actually provide their developers with precise requirements by dictating that the password field must contain exactly 8 alphanumeric characters.
It's possible that the same password will need to be entered via the phone keypad, (1 = 1, A, B, or C).
Realizing that this is terribly insecure, one way of increasing the security would be to lock the account after X bad password attempts. Often bank websites are just a front end for a horribly old mainframe application and can't change password policies.
The reason they require alphanumeric is usually an attempt to prevent SQL injection when passwords are entered. For example:
On some sites you can actually type in:
U: admin
P: ' or 't' = 't
Normally programmers get through this by using programming practices such as parameterized SQL, but I am willing to bet this is why they are doing it.
it's a toe crunching, teeth grinding issue especially when banks do it; however, I think some of the issues are with the ';' and ' ' " ' characters.
Back in the day some programmers, i suspect, thought by forcing alphanumeric characters, that people might forget their passwords easily.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Pros:
I can't remember "good" passwords anyway so remembering them is not an issue.
they don't look like passwords
they are darn near impossible to guess (128 bits of entropy)
easy to generate (offloads the "good PRNG" problem)
Cons:
???
In particular; what about for passwords that computers enter like for databases logins on some setups.
One major con is that you don't necessarily have "128 bits of entropy" as stated in the original question.
Many GUID Algorithms have information embedded in them in predictable patterns, for example the MAC address of the computer, the date/time, or an incrementing sequence. Cryptanalysis of the WinAPI GUID has shown given the initial state one can predict up to next 250,000 GUIDs returned by the function UuidCreate
For example, I have about a 50% chance of guessing the first digit in the first position of the third group of digits since it will be either 1 (for V1 guids) or 4 (for V4 guids)
Source: http://en.wikipedia.org/wiki/Globally_Unique_Identifier
Cons:
You will write them down somewhere.
You will probably email them, or write them down again if you need to tell anyone else.
They may be too long for certain systems.
They're practically impossible to memorize, so you might change them more frequently then desired.
So unless they're system passwords which change rarely, I doubt they are good passwords.
Con:
It would be nearly impossible to remember a 32-byte alpha numeric string.
If you really want a secure password, consider a passphrase instead. A long passphrase is easily remembered, and very difficult to brute force.
Con:
Some systems have limits on the maximum length of passwords. If you're only using hex digits this can limit your entropy to perhaps as little as 32 bits.
Cons:
Password fields are not always long enough.
More difficult to enter - you'd probably store the password in a program, not in your head. That's a bit of a security problem...
... pros:
Nobody will be able to force your password out of you.
Big-random-number passwords have been done before. They're called OTPs, and are much more secure than what you're suggesting because they change over time, and tend to be generated by secure devices. Of course this is only relevant if you are designing a password system.
Does anyone ever need to enter it as a password? Or do you want to use it as a one-time thing? Because seriously, no one wants to enter a GUID in a passwordfield. People have trouble enough as it is, entering WEP/WPA2 wifi network keys. And most of the time, those are one-timers.
#Miyagi: that's the most obvious con ofcourse. They'll have to write it down.
Technically they would be good passwords
In real life, they would be horrible passwords
You would end up having to write down the passwords, use a password manager, or some other form to actually use the password... in a way moving the failure point from the password to another aspect.
Consider using passphrases. Sentences with substitutions for certain letters or other characters, and for numbers, typing them with the SHIFT, converting easy to remember numbers in to well defined character sequences.
For example bcs19850101bcs would be bcs!(*%)!)!bcs
If you want a secure password that you wish to leave to a password manager on a UNIX-like system, you're much better just pulling one from /dev/random and encoding it into something readable. for 128 bits of entropy you can use something simple like
head -c 16 /dev/random | openssl enc -a -e
which gives a password like 5eqIviKu4pFTqSPnYosVKg==
not unreasonably long, secure, random, suicide to try to remember.
Edit: added benefits of this method over UUID include extra security in the PRNG (/dev/random) and shorter passwords, similar shortfalls
I recently wrote code to convert the first 64 bits of a checksum into a sequence of four English words. This makes a good checksum (much easier to remember than a hex mess), but I'm not sure I'd trust it as a password. If you're protecting something secure, you should use a strong password that you memorize and don't write down. If not, then any old password will do.
I think what you actually want is a cryptographically-random number, not a GUID. GUIDs and UUIDs are not random -- as JohnFx said, they tend to incorporate discoverable values like the MAC address or current timestamp, in order to guarantee uniqueness.
Instead, you should look at whatever crypto API is available to you and find a source of high-entropy random numbers. Make sure the documentation promises the output is suitable for cryptography, not just a regular PRNG. For example, /dev/random on Unix systems is a good source. Then just unroll as many random bytes as you want.
Personally this seems a bit too hardcore. I'd rather generate strings that contain a bit less entropy per character, but are easier to type and remember. For example, there are several algorithms that combine random syllables to create pronounceable nonsense words; intersperse some digits and punctuation, and you've got a good password.
I like my passwords strong and pronouncable (try one of the sites listed here for an online demo, be sure to pick a "v2" site to get the pronounciation-guide).
Con: You can't retype it, which means you will have to copy and paste. If you have your password management program on your system, not really a problem. But if you end up on a system where you don't, just retyping the thing will be very difficult.
And then after you try a couple of times you get locked out ....
Life could get very annoying.
Even if you write it down, a good password is something you can type consistently without errors.