linuxism

transaction ; 트랜잭션

출처 - terms.co.kr

[Spring] TransactionManager와 DataSource

2009/10/27 16:48 in 테크 노트 (Tech Note)

출처 - http://tinywolf.tistory.com/107

===================================================================================

출처 - http://bbaeggar.tistory.com/86

In computing, Unix-like operating systems use the shadow password database mechanism to increase the security level of passwords by restricting all but highly privileged users' access to encrypted password data. Typically, that data is kept in files owned by and accessible only by the super user (i.e., on Unix-like systems, the root user, and on many others, the administrator account).

[edit]Design

Systems administrators can reduce the likelihood of brute force attacks by making the list of hashed passwords unreadable by unprivileged users. The obvious way to do this is to make the passwd database itself readable only by the root user. However, this would restrict access to other data in the file such as username-to-userid mappings, which would break many existing utilities and provisions. One solution is a "shadow" password file to hold the password hashes separate from the other data in the world-readable passwd file. For local files, this is usually /etc/shadow on Linux and Unix systems, or /etc/master.passwd on BSD systems; each is readable only by root. (Root access to the data is considered acceptable since on systems with the traditional "all-powerful root" security model, the root user would be able to obtain the information in other ways in any case). Virtually all recent Unix-likeoperating systems use shadowed passwords.

The shadow password file does not entirely solve the problem of attacker access to hashed passwords, as some network authentication schemes operate by transmitting the encrypted password over the network (sometimes in cleartext^{[citation needed]}), making it vulnerable to interception. Copies of system data, such as system backups written to tape or optical media, can also become a means for illicitly obtaining hashed passwords. In addition, the functions used by legitimate password-checking programs need to be written in such a way that malicious programs cannot make large numbers of authentication checks at high rates of speed.

[edit]Usage

On a system without shadowed passwords (typically older Unix systems dating from before 1990 or so), the passwd file holds the following user information for each user account:

• Username
• Salt combined with the current hash of the user's password (usually produced from a cryptographic hash function)
• Password expiration information
• User ID (UID)
• Default group ID (GID)
• Full name
• Home directory path
• Login shell

The passwd file is readable by all users so that name service switch can work (e.g., to ensure that user names are shown when the user lists the contents of a folder), but only the root user can write to it. This means that an attacker with unprivileged access to the system can obtain the hashed form of every user's password. Those values can be used to mount abrute force attack offline, testing possible passwords against the hashed passwords relatively quickly without alerting system security arrangements designed to detect an abnormal number of failed login attempts. Users often select passwords vulnerable to such password cracking techniques.^[1]

With a shadowed password scheme in use, the /etc/passwd file typically shows a character such as '*', or 'x' in the password field for each user instead of the hashed password, and /etc/shadow usually contains the following user information:

• User login name
• salt and hashed password OR a status exception value e.g.:
  • "$id$salt$encrypted", where "$id" is the hashing algorithm used (On GNU/Linux, "$1$" stands for MD5, "$2$" is Blowfish, "$5$" is SHA-256 and "$6$" is SHA-512, crypt(3) manpage, other Unix may have different values, like NetBSD).
  • "NP" or "!" or null - No password, the account has no password.
  • "LK" or "*" - the account is Locked, user will be unable to log-in
  • "!!" - the password has expired
• Days since epoch of last password change
• Days until change allowed
• Days before change required
• Days warning for expiration
• Days before account inactive
• Days since Epoch when account expires
• Reserved

The format of the shadow file is simple, and basically identical to that of the password file, to wit, one line per user, ordered fields on each line, and fields separated by colons. Many systems require the order of user lines in the shadow file be identical to the order of the corresponding users in the password file.

To modify the contents of the shadow file on most systems, users generally invoke the passwd program, which in turn largely depends on PAM. For example, the type of hash used is dictated by the configuration of the pam_unix.so module. By default, the MD5 hash has been used, while current modules are also capable of stronger hashes such as blowfish,SHA256 and SHA512.

[edit]History

Password shadowing first appeared in UNIX systems with the development of System V Release 3.2 in 1988 and BSD4.3 Reno in 1990. But, vendors who had performed ports from earlier UNIX releases did not always include the new password shadowing features in their releases, leaving users of those systems exposed to password file attacks.

System administrators may also arrange for the storage of passwords in distributed databases such as NIS and LDAP, rather than in files on each connected system. In the case of NIS, the shadow password mechanism is often still used on the NIS servers; in other distributed mechanisms the problem of access to the various user authentication components is handled by the security mechanisms of the underlying data repository.

In 1987 the author of the original Shadow Password Suite, Julie Haugh, experienced a computer break-in and wrote the initial release of the Shadow Suite containing the login, passwdand su commands. The original release, written for the SCO Xenix operating system, quickly got ported to other platforms. The Shadow Suite was ported to Linux in 1992 one year after the original announcement of the Linux project, and was included in many early distributions, and continues to be included in many current Linux distributions.

[edit]See also

• Crypt (Unix)
• Key derivation function
• Unix security
• vipw