Sponsored Content
Full Discussion: Password rules not effective
Special Forums Cybersecurity Password rules not effective Post 302730359 by DGPickett on Monday 12th of November 2012 05:03:32 PM
Old 11-12-2012
With all the languages of the world, dictionary tests are bad. Some sort of checksum history can keep them off the last N passwords. Make a rule that every password has to have both upper and lower case, a number and a special, with no more than 3 of anything in a row, so Hello1! amd HELLo1! are not legal, but heLLo1! is OK. The breaks up phone numbers, anniversaries (the most popular?), words, names, etc.
 

7 More Discussions You Might Find Interesting

1. Cybersecurity

Changing effective user

I would like to give execution rights for a script to one user. (that's the easy part...) When that user is running the script, I would like the effective user ID to be that of the file-owner. Is this possible? (6 Replies)
Discussion started by: hilmel
6 Replies

2. UNIX for Dummies Questions & Answers

Variables for Effective Username?

Hey all, I'm glad to have found this forum as I'm trying to dive head first into Solaris 8 - been working with it for a few months now and am finally getting a bit comfortable with the layout and concepts. In any case, on to the questions... :D I was wondering how I would go about displaying... (3 Replies)
Discussion started by: QuadMonk
3 Replies

3. UNIX for Dummies Questions & Answers

most effective search ?

what's the most efficient and effective search for a file in a dir ? I see many guys use this # find - print or something as such ? and sometimes pipe it to something else ? Is there a better way of using "grep" in all of this ? thanks simon2000 (3 Replies)
Discussion started by: simon2000
3 Replies

4. UNIX for Dummies Questions & Answers

Changing the Effective Group ID

Here is my situation. On a RedHat 7.3 box, I have a user named jody. When I log in with jody and type in "id", I get the expected output: uid=1(jody) gid=1(jody) groups=1(jody), 510(test) However, I cannot figure which "id" option allows me to change the effective gid. I tried the options... (2 Replies)
Discussion started by: Jody
2 Replies

5. UNIX for Dummies Questions & Answers

Server wide password enforcement rules? 90 day force change.

Using Solaris 9 and 10. What we want to do is set up global rules for our password files to restrict all users, not only new ones set up with the rules but also the ones that have been sitting on the system for years. Is there a global way to force all users to change their password every 90... (1 Reply)
Discussion started by: LordJezo
1 Replies

6. UNIX for Dummies Questions & Answers

rules for new password?

What are the rules for choosing a new password when the old one expires? I notice when I try to use a password that is similar to my previous one then it won't take it. Got me wondering what the exact rules are- as in, how different does it have to be from previous passwords. (1 Reply)
Discussion started by: zTodd
1 Replies

7. UNIX for Dummies Questions & Answers

Real and Effective IDs

Can anyone explain me in details of Real and Effective IDs (6 Replies)
Discussion started by: kkalyan
6 Replies
pam_authtok_check(5)                                    Standards, Environments, and Macros                                   pam_authtok_check(5)

NAME
pam_authtok_check - authentication and password management module SYNOPSIS
pam_authtok_check.so.1 DESCRIPTION
pam_authtok_check provides functionality to the Password Management stack. The implementation of pam_sm_chauthtok() performs a number of checks on the construction of the newly entered password. pam_sm_chauthtok() is invoked twice by the PAM framework, once with flags set to PAM_PRELIM_CHECK, and once with flags set to PAM_UPDATE_AUTHTOK. This module only performs its checks during the first invocation. This module expects the current authentication token in the PAM_OLDAUTHTOK item, the new (to be checked) password in the PAM_AUTHTOK item, and the login name in the PAM_USER item. The checks performed by this module are: length The password length should not be less that the minimum specified in /etc/default/passwd. circular shift The password should not be a circular shift of the login name. This check may be disabled in /etc/default/passwd. complexity The password should contain at least the minimum number of characters described by the parameters MINALPHA, MINNONALPHA, MINDIGIT, and MINSPECIAL. Note that MINNONALPHA describes the same character classes as MINDIGIT and MINSPECIAL combined; therefore the user cannot specify both MINNONALPHA and MINSPECIAL (or MINDIGIT). The user must choose which of the two options to use. Furthermore, the WHITESPACE parameter determines whether whitespace characters are allowed. If unspecified MINALPHA is 2, MINNONALPHA is 1 and WHITESPACE is yes variation The old and new passwords must differ by at least the MINDIFF value specified in /etc/default/passwd. If unspecified, the default is 3. For accounts in name services which support password history checking, if prior history is defined, the new password must not match the prior passwords. dictionary checkThe password must not be based on a dictionary word. The list of words to be used for the site's dictionary can be speci- fied with DICTIONLIST. It should contain a comma-separated list of filenames, one word per line. The database that is cre- ated from these files is stored in the directory named by DICTIONDBDIR (defaults to /var/passwd). See mkpwdict(1M) for information on pre-generating the database. If neither DICTIONLIST nor DICTIONDBDIR is specified, no dictionary check is made. upper/lower caseThe password must contain at least the minimum of upper- and lower-case letters specified by the MINUPPER and MINLOWER val- ues in /etc/default/passwd. If unspecified, the defaults are 0. maximum repeats The password must not contain more consecutively repeating characters than specified by the MAXREPEATS value in /etc/default/passwd. If unspecified, no repeat character check is made. The following option may be passed to the module: debug syslog(3C) debugging information at the LOG_DEBUG level RETURN VALUES
If the password in PAM_AUTHTOK passes all tests, PAM_SUCCESS is returned. If any of the tests fail, PAM_AUTHTOK_ERR is returned. FILES
/etc/default/passwd See passwd(1) for a description of the contents. ATTRIBUTES
See attributes(5) for descriptions of the following attributes: +-----------------------------+-----------------------------+ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | +-----------------------------+-----------------------------+ |Interface Stability |Evolving | +-----------------------------+-----------------------------+ |MT Level |MT-Safe with exceptions | +-----------------------------+-----------------------------+ SEE ALSO
passwd(1), pam(3PAM), mkpwdict(1M), pam_chauthtok(3PAM), syslog(3C), libpam(3LIB), pam.conf(4), passwd(4), shadow(4), attributes(5), pam_authtok_get(5), pam_authtok_store(5), pam_dhkeys(5), pam_passwd_auth(5), pam_unix_account(5), pam_unix_auth(5), pam_unix_session(5) NOTES
The interfaces in libpam(3LIB) are MT-Safe only if each thread within the multi-threaded application uses its own PAM handle. The pam_unix(5) module is no longer supported. Similar functionality is provided by pam_authtok_check(5), pam_authtok_get(5), pam_auth- tok_store(5), pam_dhkeys(5), pam_passwd_auth(5), pam_unix_account(5), pam_unix_auth(5), and pam_unix_session(5). SunOS 5.10 4 Jun 2004 pam_authtok_check(5)
All times are GMT -4. The time now is 04:40 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy