The process of establishing that you are the person you are trying to represent is called authentication.
In other words, the authentication is a means of access control that ensures that user are who he claim
to be. Every person who uses a Unix machine has own account identified by a user ID number (UID)
that is associated with one or more usernames (or account names). Each account
also has a secret password associated with it to prevent unauthorized use. You need to know both
your username and your password to log in. When you log in, you type your password to prove to the computer
that you are who you claim to be. The computer encode some string of characters (blanks in case of Unix)
with your password and compare the result with the stored value. It never stores the password on the
server.
"After Snowden" world means that some of sophisticated methods used by NSA will inevitably trickle
down to criminals. There is a terrible rule of war: whatever new weapon that you introduce onto
the battlefield, your adversary will eventually acquire it as well. And probably sooner that
you think.
That means that now there is a bigger
danger for our financial accounts and the two factor authentication is a must. It is irrespnsible to
use any financial account without two factor authentication. end of story. Actually in our private
lives banks and other financial institutions that do not use two factor authentication for their Web
portals are better to be avoided.
In a corporate environment it is irresponsible to not to use two factor authentication to any
server that contain non-junk data.
Now you need to
segregate your Web sites (or servers) into two categories and use more complex, and unique passwords
to access highly sensitive sites such as your bank Web portal or servers with sensitive information
...
“Despite violating long-standing password guidance, writing passwords down is, if properly done
(and that means you write them on paper, not electornically),
is a valid coping mechanism in post Snowden world and but only paper media should be used. No spreadsheets
and such.
Identification is the way you tell the system who you are. Now often cell phone s used as a
method of secondary authentication. which is OK and very cheap. Authentication is the way you prove to
the system that you are who you say you are.
In any multi-user system there is a danger that your identity might be stolen.
There are three
classic ways in which you can prove yourself:
Something you know. The most familiar example is a password. In modern work this is
not enough. The theory is that if you
know the secret password for an account, you must be the owner of that account. There is a problem
with this theory: You might give your password away or have it stolen from you. If you write it down,
someone might read it. If you tell someone, that person might tell someone else. If you have a simple,
easy-to-guess password, someone might guess it or systematically crack it.
Something you have. Examples are keys, tokens, badges, smart cards, cell phones, etc you
must have to "unlock" your terminal or your account. The theory is that if you have the key or equivalent,
you must be the owner of it. The problem with this theory is that you might lose the key, it might
be stolen from you, or someone might borrow it and duplicate it. Electronic keys, badges, and smart
cards are gaining acceptance as authentication devices and as access devices for buildings and computer
rooms. With the proliferation of automatic teller machines (ATMs), people are becoming increasingly
familiar with this type of authentication.
Something you are. Examples are physiological or behavioral traits, such as your fingerprint,
handprint, retina pattern, voice, signature, or keystroke pattern. Biometric systems compare your
particular trait against the one stored for you and determine whether you are who you claim to be.
Although biometric systems occasionally reject valid users and accept invalid ones, they are generally
quite accurate. The problem with these authentication systems is that, on the whole, people aren't
comfortable using them.
Passwords are still the authentication tool of choice. Even when authentication devices like tokens
and biometric devices are used, they're usually supplements no replace conventional login IDs and passwords.
Biometrics and smartcards typically act only as a first line of defense against intruders, not as the
only defense.
When number of login with wrong password is limited to, say, seven or less, it does not matter much
how strong is your password (it still matter if the password database is stolen and run via cracker)
Username in most organization are usually generated from user first and last name. For
example first six characters of the last name, plus the first character of the first name and the
first character of the middle name or digit in case of conflicts create eight character user name.
For users that have identical first several characters of user id, the eight character can be selected
to be unique (for example 1-9). Traditionally the length of the Unix user name is limited to eight
characters although some systems now may allow longer names without implicit truncation to first
eight meaningful characters.
It is important not to kill simplicity with too much zeal. Always use AOL double word scheme.
Older flavors of Unix used to limit passwords to 8 characters. In this case it difficult to use
very effective and use easily memorizable AOL-style double word scheme for password (e.g. nj0777-florham,
Dogs&&Cats, Geo-Prism-1.6L), but it is still possible.
Authentication can be performed not only via passwords, but also using certificates, Smartcards,
security tokens (SecurID is one example) or any combination of those (two
factor authentication). SMS messages
are widely used in Eastern Europe and Russia and now make their way into the USA. Voice dictation via
phone like is also widely used. Two factor authentication is now standard for any reasonable financial
portal (E*TRADE and (in the past, before it switched to SMS) Paypal provide users with free security tokens)
to minimize the possibility for unauthorized persons to gain access to the account. Google provides
a USB stick. Using security token makes "phishing attacks" useless as one time password is unique for
each logging attempt.
Web sites, especially financial web sites are even more difficult to secure as here there are
clear incentives to break-in. Actually financial web site like Vanguard are in forefront of implementing
simple but effective control measures mentioned above. To avoid "fake sites" companies like Vanguard
implemented a random, user-selectable "mascot" for each user,
which make each login page unique and substantially complicated creation of fake sites.
Passwords remain the simplest and the most common form of authentication, which now should be abandoned
in favor or two factor authentication with the sell phone providing security code or, better, a hardware
token. With regular passwords, the most important thing is not strength of the password per ser
(although it should satisfy some minimal requirements to prevent cracking in case the whole password
database is stolen like was recently the case with Yahoo), but three additional measures that help to
block dictionary style attacks:
Assume that there is hunting season for large commercial sites accounts from various intelligence
agencies and hackers.
Never use the same password for several sites. With AOL scheme use the second word to
individualize
the password for each site. Each server or site should have a unique password. Even simple scheme
like the first word reflecting the current changeable password and the second word reflecting some
information about the server or site. For example DL380g-nyc for a server. For
a Web site you can use location or some word associated with the time ( the name of creator, famous
company, capital, etc) as the second part of password (for example "Msoft" for Californian
sites or "Devils" for NJ , or even zip07929 -- zip code of location). But now in no way you
should ever use the same password for two servers or site. That's two dangerous.
Length of password is much more important then its strength. Enforcing length of, say 10 you
essentially force the users (and sysadmins) to use two words combinations (AOL-style) for password,
which is a good idea anyway. Which is the only way to diminish chances that you password
will be cracked if a file that contains hashes is stolen. See Password
Policy in 'After Snowden" World
Limiting number of failed login attempts to, less then a dozen (say 7 but never three if you
do not want a flow to tickets connected with inability to login ;-). There is no difference between
seven attempts and three attempts from the point of view of guessing the password. But for sure
three attempt and you are out rule is the most sure way to create a stream of useless helpdesk
tickets for your organization). Brute force attack with just seven attempts is pretty much meaningless
- the attacker does not have any chances to succeed.
Increasing waiting period after each failed login attempt or series of attempts.
This is a must in "After Snowden" world.
Controlling IPs from which login is performed and using such an IP as an additional authentication
parameter or even as a hidden part of password. If the IP address from which authentication is
performed is "new" --- has no history of previous successful authentication attempts, then additional
questions should be asked before allowing access. This is especially important in case of Web
access. Most financial sites now use "pre-authentication" for any "new" IP: they first ask
set of predefined questions about account owner history (maiden name of your mother, name of High
School that you attended, brand of your first car, etc). Only if you answered those questions correctly
they allow you to enter password.
Using unique password for each account you have. In real life if somebody steals
the shadow file from some server or database of account from a cloud provider or Web merchant the
only realistic goal in this context is pretty evil: to reuse cracked accounts for attacking other
accounts. Users and sysadmins often have the same password on multiple servers/sites; and in
"after Snowden" world this is a very bad idea -- you need to have some algorithm of individualization
of passwords for each account you have -- no more any two identical passwords can be used.
Now this is a must.
Users and sysadmins often have the same password on multiple servers; and in "after
Snowden" world this is a very bad idea -- you need to have some algorithm of individualization
of passwords for each account you have -- no more any two identical passwords can be used.
Now this is a must.
Especially bad idea is to have non-unique password for accounts with financial information.
Authentication is not limited to servers and web sites, of course. Network equipment like routers
proved to be particularly difficult to secure and often are the point of attack.
Contrary to popular belief, Unix passwords cannot be decrypted from the content of /etc/shadow
file, even if the file was stolen. Unix passwords are encrypted with a one way function. The login program
accepts the text you enter at the "Password:" prompt and then encrypt predefined string using specified
cryptographic algorithm. The results of that algorithm are then compared against the encrypted form
of your Unix password stored in the /etc/shadow file. Unfortunately not all cloud providers
and Web merchants use this algorithms. Some store "real" passwords which is a blunder.
On a more technical level, the password that you enter is used as a key to encrypt a 64-bit block(s)
of NULLs. The first seven bits of each character are extracted to form a 56-bit key. This means that
only eight characters are significant in a standard Unix password (Modern Unixes switched to MD5 hashes;
Linux now implemented longer passwords using MD5 hashes). The E-table is then modified using the salt,
which is a 12-bit value, coerced into the first two chars of the stored password. The salt's purpose
is to make precompiled password lists more time consuming to use. DES is then invoked for 25 iterations.
The 64-bit output block is then converted to a 64-character alphabet (A-Z,a-z,".","/") string.
Unix password auditing software (aka Password Checkers/Crackers)
uses wordlists to implement a dictionary attack against /etc/shadow file. As such this
attacks can be replicated only if hacker managed to stole/etc/shadowfile. But
stealing it means that you should be root on the particular server. So there is a Catch 22 situation.
Generally cracking passwords makes sense if and only if users reuse passwords on different servers.
So the first rule here is not increasing the strength of the password to absurd levels, but requiring
that user do not use the same password for accounts on different servers by adding server specific suffix
or prefix much like salt in Unix password encryption scheme. Moreover, any password used for web site
should never be used to secure your financial data. Good practice requires some mnemonic schemes for
passwords:
"useless" web sites can have short and easy AOL style password (let's say two four letter words
and delimiter),
More complex for private servers (passwords should contain special symbols and can be not two
word type but three word phrase)
Two factor authentication on all (and I mean all) servers with financial data. If the financial
site or bank does not provide two factor authentication consider moving to the site that provide
this service.
If passwords are unique for each server and number of login attempts is limited and after certain
amount of attempts account is blocked for an hour or so even very weak passwords are "unbreakable" from
a theoretical standpoint. So excessive zeal in choosing "extra-secure" passwords often backfires
as users often forget them and tend to use the same password on different servers. Using the same
password for two or more different servers is a big "no-no" in "After Snowden" world. Similar to
use of non-encrypted protocol for connection. Essentially FTP and Telnet now needs to be outlawed for
business critical servers.
Excessive zeal in choosing strong
random passwords often backfire. Now you are better off using longer easily memorizable passwords
for each server (AOL two word approach or similar is a good idea) than one strong password for
all you accounts on multiple servers. In "After Snowden" world this is a big no-no.
When strong passwords are really
needed two factor authentication should be used
To ensure better password security your can use the following measures (not all of them make sense
in the particular organization but some definitely make sense):
Force users to use AOL password scheme by increasing the minimal length of passwords, but
try to avoid the overcomplexity trap. It is important not to overdo increasing requirements for password
complexity -- a single uppercase character, a single delimiter and a single digit are more then adequate
requirements. If higher level of security is required, then the implementation of certificate,
security token or card is a better solution that any tinkering with the complexity of plain vanilla
passwords. Again one of the key consideration in implementing any simple password related security
measure is its effect on the on flow of tickets to the helpdesk. In "After Snowden" world smartcards
are now the standard way to increase the level of password security in most large organizations.
Always enable the number of unsuccessful login protection, but do not set it too low (7
is typically OK unless you have very stupid users, but 3 is too low; 5 is in between, but still pretty
annoying as for number of helpdesk tickets generated). If you know how to use PAM instead of disabling
the account it is better to double the pause after each unsuccessful login attempt or series
of attempts. Implementation of "known IPs" feature requires custom PAM module, but it is a very effective
and highly recommended measure. It prevents brute force attacks from "zombie" PCs and at the same
time does not inconvenience users. Together those two measures limit typical for large organizations
flow of useless tickets to helpdesk from users who lock themselves out, while still providing reasonable
level of security.
Root password should be complex long password or no password at all (hash that can't be generated
by the chosen encryption scheme, for example string "NA") SSH certificate should be used instead.
You can always use sudo on Linux or RBAC (on Solaris)
to get to root from a regular account and this provides additional level of security. Do not allow
telnet root logins. SSH root logins should require certificates. This is probably the simplest way
to increase root password security. Completely disable root login using password. That instantly
creates the opportunity to limit root access to selected group of people without playing with PAM.
Right now only Ubuntu has sudo enabled by default and root password is disabled, but these scheme
can be adopted in all major Linux distributions as sudo is now preinstalled on all of them (included
in default installation and is supported package). Please remember that on most servers with additional
remote control cards, remote control password is equivalent to root and would be protected with the
same level of attention. Often organization are pretty lax and stupid in this area.
Educate users about AOL scheme of creating password, as well as
"good" password
selection criteria, It make sense to use a pro-active password checker to verify that
passwords are compliant with the chosen policy, but excessive length typically force the users to
use AOL scheme. The key here is to force the users to select longer AOL-style two word passwords.
Random passwords is a trap you should avoid. They often written by users and instead of
improving compromise security. You need something like that use "one time pad" approach instead.
For example, random generated passwords are justifiable mainly for standard accounts like root (and
even in this case only half of the password (3 or four letter combination) should be random as longer
random strings are really difficult to remember, see
Root Security)
For those devices that do not support SSH certificates, root password always use at least
12 characters as the minimum length and they should be unique for each router or other device (although
scheme incorporating part of DNS name as the second word of AOL style password can be used).
Casio Watches can be used as a databank of critical root passwords (but never use any smart watches).
The key problem here is that when people leave organization it is not always possible to know correctly
to which systems they have root access so total replacement of all password in their zone of responsibility
should be done.
For regular users implement password aging. But interval should be long enough, for example
180 day at least to make this measure less troublesome, but there should be an interval. One month
changes just annoy users and create a flow on useless helpdesk tickets. Sometimes unused accounts
are fallen through the cracks in the organization checks. Expiration period guarantee that
they eventually will be disabled automatically. The period should be long enough not to affect regular
users (for example, one year). If this is not done then often accounts for users who left three years
still exist on some systems no matter what measures you take and what audits were performed.
If you need to use guest accounts, use only restricted shells for them. Eliminate all "default"
guest accounts. They should have unique for the organization names like mgb_guest
Disable the ability to log in to system "placeholder" accounts like sys by using "fake" shell
(like nologin). Delete well-known accounts that are not needed
Make sure all accounts have passwords or "*" in the password field and automatically check
for this daily (at least for all system accounts with UID less then 100 -they all generally
should have "*" in the password field of the shadow file.
Use wheel group and corresponding
PAM module for users who are allowed to switch to root.
Make sure you have reasonable default file protections for newly created files. For high
security systems (and only for them) do not allow group/world read/write access by using a "umask"
value of 022, 027, or 077.
Codify rules and policies for operating as the "super user" Monitor compliance with those
use using automatic tools. Do not adopt rules that can't be automatically checked.
Standardize and write-protect the "root" account's startup files. Minimize the number of users
with "super user" privileges
Minimize the number of accounts on security sensitive servers and "critical" hosts
Periodically check from cron soundness of all accounts settings using automatic tools.
The simplest such tools is probably pwck command; better tools are scripts from hardening
tools like Titan, JASS or Bastille
NOTE: Errors in the /etc/passwd file can cause many problems including the inability
to login as root. Especially common cause of locking of root account is change of the shell when you
specify an incorrect path to the new shell (this is common problem on Solaris where root account by
default uses Born shell instead of Korn shell (blunder that costs many hours of lost time for Solaris
administrators). The pwck command is a quick way to test the file and should be run whenever
you make manual edits.
This is mostly an internal vulnerability as in no way you should be able to authenticate to internal
system from Internet for security sensitive systems. Only from private VPN. It is an external
vulnerability for ISPs and small companies that does no use VPN for this purpose. In this case one time
password system or security token should be used to avoid cracking of password database. See recent Yahoo
hack for details
Yahoo discloses
hack of 1 billion accounts
Google provides two factor authentication which as we know now Podesta did not use which lead
to huge embarrassment when his emails were stolen due to simplistic phishing scheme (he proved to be
completely incompetent idiot as for computer security, as most of Hillary Clinton entourage;
he was too
lazy to use two factor authentication that Google provides):
Signing in to your account will work a little differently
You'll enter your password. Whenever you sign in to Google, you'll enter your password as usual.
You'll be asked for something else. Then, a code will be sent to your phone via text, voice
call, or our mobile app. Or, if you have a Security Key, you can insert it into your computer’s
USB port.
The most common Web mail password vulnerabilities are:
users accounts with widely known or openly displayed passwords;
Stupid (truthful) answers on security question (you should use answer for some fictional character
or relative, not yourself)
Failure to configure the account for the two factor authentication
The best defense against all of these vulnerabilities is a strong authentication policy that includes
usage of Secure Id or smartcards. We also need to create detailed instructions for users for strong
passwords creation; explicit rules for users to ensure their passwords remain secure; a process for
IT staff to promptly replace weak/insecure/default or widely known passwords and to promptly lock down
inactive or close down unused accounts; and a proactive and regular process of checking all passwords
for strength and complexity.
It seems some of us are, in the year of our lord 2021, still reusing the same password for
multiple sites, plugging personal gear into work networks, and perhaps overly relying on
browser-managed passwords, judging from this poll.
ThycoticCentrify, formed from a merger between two computer access management firms, said it
surveyed about 8,000 people, and
reports just under a quarter admitted they reuse passwords across multiple websites –
a cybersecurity no-no because it opens you up to credential stuffing .
Meanwhile, about half of those working for large (5,000+ headcount) companies said they
hadn't received cybersecurity training in the past 12 months, even as the vast majority of all
those polled said they'd seen an increase in the volume of phishing messages their org had
received over the past year.
"More than a third of employees continue to save passwords within their internet browsers on
all of their personal and work devices," said Carson. "By cracking only one of those devices,
an attacker can easily access all the passwords stored within the user's browser. This makes it
so much easier for an attacker to elevate privileges without being detected and gain access to
the user's email, company cloud applications, or even sensitive data.
"If the employee has saved multiple passwords within the internet browser, an attacker can
readily see whether they are all the same or simple variations such as one character
difference."
Using a password manager, even one built into a browser, with complex, randomly generated
passwords is arguably better than asking people to memorize weak or guessable ones or reuse the
same credentials over and over for multiple services. That said, ThycoticCentrify's argument
appears to be that companies should move beyond relying just on passwords: they should consider
better ways to reliably and securely authenticate users when accessing resources, using things
like multi-factor authentication.
... ... ...
Finally, though most people responding to the survey acknowledged their business could be
targeted by cyber-criminals, a mere 16 per cent of respondents felt their business was at a
"very high risk" of catching the wrong end of a cybersecurity attack. The spray-and-pwn tactics
of ransomware gangs, such as the crews who targeted ageing Accellion
file-transfer appliances , hasn't quite sunk in for all. ®
Monitoring failed login attempts on Linux
Failed logins can be legitimate human error or attempts to hack your Linux system, but either way they might flag something that
warrants attention.
Repeated failed login attempts on a Linux server can indicate that someone is trying to break into an account or might only
mean that someone forgot their password or is mistyping it. In this post, we look at how you can check for failed login
attempts and check your system's settings to see when accounts will be locked to deal with the problem.
One of the first things you need to know is how to check if logins are failing. The command below looks for indications of
failed logins in the
/var/log/auth.log
file used on Ubuntu and related systems.
When someone tries logging in with a wrong or misspelled password, failed logins will show up as in the lines below:
$ sudo grep "Failed password" /var/log/auth.log | head -3
Nov 17 15:08:39 localhost sshd[621893]: Failed password for nemo from 192.168.0.7 port 8132 ssh2
Nov 17 15:09:13 localhost sshd[621893]: Failed password for nemo from 192.168.0.7 port 8132 ssh2
You could summarize instances of failed logins by account with a command like this:
That command summarizes failed logins by username (ninth column in the grep output). It avoids looking at lines containing the
word "COMMAND" to skip over inquiries that contain the "Failed passwords" phrase (e.g., someone running the command that was
run above). The "times:" string suggests that there were more repeated attempts than the number reported. These come from
lines containing "message repeated 5 times:" that may be added to the log file when a password is entered incorrectly a
number of times in quick succession.
Another thing you might want to check is where the failed login attempts are coming from. For that, change the field that
you're focusing on from the ninth to the eleventh as in this example:
It might be especially suspicious, for example, if you're seeing failed logins for multiple users from a single system.
In RHEL, Centos and related systems, you'll find the messages related to failed logins in the
/var/log/secure
file.
You can use basically the same query as shown above to get a count. Just change the file name as shown here:
The retail environment has experienced far-reaching changes over the past year. With the pandemic fundamentally shifting
how customers interact with retailers, digital sales had to evolve at warp...
Checking faillog
You might check out the
faillog
command, but this command looks at the
/var/log/faillog
file
which does not seem to be used on many systems these days. If you use the
faillog -a
command
and get output like that shown below listing 12/31/69 as in the time columns, it's clear this file is
not
in
use.
$ faillog -a
Login Failures Maximum Latest On
root 0 0 12/31/69 19:00:00 -0500
daemon 0 0 12/31/69 19:00:00 -0500
bin 0 0 12/31/69 19:00:00 -0500
sys 0 0 12/31/69 19:00:00 -0500
The dates and times shown refer back to the beginning of Unix (01/01/70)--probably corrected for the local time zone. If you
run the commands shown below, you can verify that the file is not empty, but contains no real data:
If the
faillog
file is actually in use, you should see recent activity and no
references to 1969.
How to respond
Failed logins can happen for many reasons. It may be that one of your users tried to log in with their caps-lock key on and
didn't notice. Maybe they recently changed their password and forgot that they did so and were trying the old one. Maybe
they're trying the password they use on a different system. If one particular account frequently shows up when you run your
queries, you might look into it. However, an occasional failed login attempt is fairly common.
SponsoredPost
Sponsored by
Dell
Technologies and Intel®
AeroFarms takes vertical farming to new heights with edge and AI solutions that deliver data-driven insights.
Checking your settings
To see how your system is set up to deal with failed logins, check out the
/etc/pam.d/common-auth
file
. It's used on systems with the Linux Pluggable Authentication Modules (PAM). Two settings in this file control
how many failed login attempts will be tolerated before an account is temporarily locked and how long the account will be
locked.
A line like this one will have PAM locking an account after six failed login attempts. The lockout will last for five minutes
(300 seconds).
Occasional failed logins are to be expected, but it's still a good idea to be familiar with how your system is configured and
run a query from time to time to get a handle on how much of this kind of activity is taking place. One good way to do this is
to run the query as a
cron
job and email the output to yourself.
In a
previous article , I described the flow of an application calling
PAM libraries for authentication at a very high level. In this article, we will walk
through the configuration files for a local sudo command.
When using sudo , we switch users and do something. This privilege change
requires verification that we are who we say we are and are allowed to perform the given
action. The /etc/sudoers file controls who can do what, but the process still
calls PAM for any authentication checks. As a part of these calls, the process identifies
itself, and then libpam looks for a matching configuration file in the
/etc/pam.d directory.
$ cat /etc/pam.d/sudo
#%PAM-1.0
#Type ReturnCode Modules Options
auth include system-auth
account include system-auth
password include system-auth
session optional pam_keyinit.so revoke
session required pam_limits.so
session include system-auth
Like many other *.d
directories , package management may add or remove a file from this directory. The
sudo RPM adds the /etc/pam.d/sudo file.
An upstream version might have a variety of entries, but this distribution-provided package
includes a configuration file that has several include statements to the common
/etc/pam.d/system-auth file which is supplied by the pam
package.
Image Configuration file fields
The first field in this file identifies a Type of call made to PAM. Lines of the same type
are grouped together. There are four types: auth, account, password, and session. Look at
man pam for a description of each type.
The second field is known as the ReturnCode . This field lets PAM know how to handle the
results of the module test. Return codes indicate whether a test is required or optional. The
codes might also be used to indicate the line is not a module test with options but rather the
name of another configuration file with additional checks. A full description of the return
codes is found in man pam.conf , and the most common ones are discussed later in
this article.
The rest of the line contains the module name and options for that module. The module name
must match a module available in the /etc/lib64/security directory. The options
may be different depending on the type of call made. Some modules only perform tests for some
types of calls. Use the man page for each module to see examples and learn about the uses and
options available.
The order of entries within a type of call matters. This is mostly due to how the return
codes are processed, but in some cases because of a module action. When libpam
receives a "done" or "die" message, it reports the overall result back to the calling
process.
The configuration for sudo has several include lines. These lines tell
libpam to include all lines of given type from the configuration file specified.
There is also a substack option, which is similar in how it includes lines from a given
configuration file, but on a "done" or "die," it reports back to the substack instruction
instead of the original process calling libpam . Older versions of PAM had other
variations on how other configuration files were included. For example, when I started
exploring PAM almost 20 years ago, there was a specific module called with the configuration
files as an argument. The keyword "include" was not valid for the ReturnCode
field.
Return codes in the central configuration files
The /etc/pam.d/sudo file shown earlier is pretty short. Three of the four call
types have only an include of another file. The /etc/pam.d/system-auth file is
more typical of a configuration file, with many checks for each type of call.
$ cat /etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth sufficient pam_sss.so forward_pass
auth required pam_deny.so
...omitted...
The required keyword is perhaps the most common. It indicates that the module must
pass the check for an overall pass to be handed back to the application. However, even on a
failure, the following lines in that type will still be checked. This is a long time practice
of not sharing any reason for an authentication failure. On systems 20 years ago, it might have
been possible to guess how the authentication failed by how long it took to fail.
The requisite keyword is similar to required in that the check must pass, but
in the case of a failure, it returns a "die" message. Requisite lets libpam
know that the following lines will not be checked, and to inform the calling process of the
overall results -- in this case, a failure.
The sufficient keyword is almost the opposite of requisite . On success, a
"done" message is returned, and libpam goes ahead and sends its overall results
back to the calling application. Other results from this module are ignored, and checking
continues.
The sufficient keyword is common when there could be multiple ways of verifying a
criterion. For example, when verifying a password, the user might be defined in the local
/etc/passwd and /etc/shadow files, or they might only be defined in a
central system accessed with sssd . The pam_unix module checks the
local files. If there is success, there is no need to continue and check the centralized
services. However, if the user is not defined locally, we do not want to record a failure, we
want to ignore the result and try the pam_sss module. Since the sufficient
keyword never truly fails, it is common to add a required pam_deny line after a
series of sufficient lines. The pam_deny module always fails much like the
/bin/false executable.
The optional keyword is similar to sufficient in that it ignores any failures.
However, on success, it acts more like the required keyword by setting an "ok" value and
continuing to perform any additional checks.
Since both requisite and sufficient can be exit points from the stack of
modules, the order in the configuration file is important. Lines after those keywords may or
may not get executed.
Complex return codes
Beyond the simple keyword syntax, complex return codes are defined with key-value pairs
inside square brackets. The /etc/pam.d/system-auth file has a sample in the
session section of the more complex syntax.
You can find the complex syntax matching each keyword in the pam.conf man page.
The - shown above is also defined in the man page. It indicates that logging can
be skipped if the module is not installed on the system.
What's next?
Now that we can walk through when a call and exit occurs with libpam , the next
step is to better understand the use case for each module. Most modules have a man page that
explains the use and shows examples of lines that should appear in the pam.d
configuration files. Some of the modules also reference supplemental files in the
/etc/security directory. Those files are well commented and also often have their
own man page. The pam_pwquality and pam_limits modules are good
examples to get started with.
Wrap up
In the next article, I will walk through some of the changes made using the
authconfig utility. If you want to jump ahead to editing files yourself and you
have a Red Hat Learning Subscription, check out the chapter on PAM in the
Red Hat Security: Linux in Physical, Virtual, and Cloud (RH415) course.
Pluggable Authentication Modules (PAM) have been around since 1997. I was taught that PAM originated from Sun's Solaris, and it
does appear that the first enterprise use and popularization occurred there. However, according to a 1997 article I found, the first
full implementation was the Linux-PAM deployment. The article is still available from
Linux Journal . The basic premise and implementation have
not changed since then. There are some new keywords and many new modules, but overall the process is the same as 20 years ago.
As the A in PAM indicates, PAM is about authentication. In most cases, when you log in to a system via a console or from
across the network with SSH or
Cockpit , PAM is involved. It doesn't matter if the user accounts are held locally or in a centralized location. For as much
as it is used, it not common to manipulate the PAM configuration files directly. Other utilities do it for you. Many changes are
made at installation, such as when installing the sssd RPM or using the ipa-client-install utility. The
most common additional configurations can be handled by authconfig (RHEL7 and older) or authselect (RHEL8),
or even through the Cockpit web interface. Most administrators do not learn about PAM configuration files until they get involved
in advanced authentication and security topics.
What do we gain with PAM?
PAM separates the standard and specialized tasks of authentication from applications. Programs such as login ,
gdm , sshd , ftpd , and many more all want to know that a user is who they say they are, yet
there are many ways to do that. A user can provide a user name and password credential which can be stored locally or remotely with
LDAP or Kerberos. A user can also provide a fingerprint or a certificate as a credential. It would be painful to ask each application
developer to rewrite the authentication checks for each new method. A call to PAM libraries leaves the checks to authentication experts.
PAM is pluggable in that we can have different applications run different tests and modular in that we can add new methods with new
libraries.
Let's look at the high-level steps taken when a locally-defined user logs into a text-based console:
The login application prompts for a user name and password, then makes a libpam authentication call to ask, "Is
this user who they say they are?" The pam_unix module is responsible for checking the local account authentication.
Other modules may also be checked, and ultimately the result is passed back to the login process.
The login process next asks, "Is this user allowed to connect?", then makes an account call to libpam . The
pam_unix module checks for things like whether the password has expired. Other modules might check host or time-based
access control lists. An overall response is handed back to the process.
If the password has expired, the application responds. Some applications simply fail to log in the user. The login process
prompts the user for a new password.
To get the password verified and written to the correct location, the login process makes a password call to libpam
. The pam_unix module writes to the local shadow file. Other modules may also be called to verify the password
strength.
If the login process is continuing at this point, it is ready to create the session. A session call to libpam
results in the pam_unix module writing a login timestamp to the wtmp file. Other modules enable X11 authentication
or SELinux user contexts.
On logout, when the session is closed, another session call can be made to libpam . This is when the pam_unix
module writes the logout timestamp to the wtmp file.
There are many components to PAM
If you make a change to authentication using a program such as authconfig or authselect and want to
see what changed, here are some of the places to look:
/usr/lib64/security
A collection of PAM libraries that perform various checks. Most of these modules have man pages to explain the use case and options
available.
/etc/pam.d
A collection of configuration files for applications that call libpam . These files define which modules are checked,
with what options, in which order, and how to handle the result. These files may be added to the system when an application is installed
and are frequently edited by other utilities.
Since there are several checks done by all applications, these files may also have include statements to call other configuration
files in this directory. Most shared modules are found in the system-auth file for local authentication and the password-auth file
for applications listening for remote connections.
/etc/security
A collection of additional configuration files for specific modules. Some modules, such as pam_access and pam_time
, allow additional granularity for checks. When an application configuration file calls these modules, the checks are completed
using the additional information from its corresponding supplemental configuration files. Other modules, like pam_pwquality
, make it easier for other utilities to modify the configuration by placing all the options in a separate file instead of
on the module line in the application configuration file.
/var/log/secure
Most security and authentication errors are reported to this log file. Permissions are configured on this file to restrict access.
man pam
This man page describes the overall process, including the types of calls and a list of files involved.
man pam.conf
This man page describes the overall format and defines keywords and fields for the pam.d configuration files.
man -k pam_
This search of man pages lists pages available for modules installed.
Wrap up
PAM allows for a much more robust authentication environment than per-application services could provide. It has been in Linux
for many, many years, and is involved with nearly all user identification processes.
In the next article, I will walk through the format of the /etc/pam.d configuration files.
Dennis MacAlistair Ritchie's was "dmac," Bourne's was "bourne," Schmidt's was "wendy!!!"
(his wife's name), Feldman's was "axlotl," and Kernighan's was "/.,/.,." Four more passwords
were cracked by Arthur Krewat: Ozalp Babaolu's was "12ucdort," Howard Katseff's was "graduat;,"
Tom London's was "..pnn521," Bob Fabry's was "561cml.." and Ken Thompson's was "p/q2-q4!"
(chess notation for a common opening move). BSD 3 used Descrypt for password hashing, which
limited passwords to eight characters, salted with 12 bits of entropy.
It's rare that
websites are brute force hacked. Usually people gain access via malware or some other security
hole, escalate their privileges and then grab a copy of the password hashes. Then they can run
the password file through a list of other known passwords to catch the low hanging fruit, then
use various other brute force attacks to try to get the rest. If you've got a difficult enough
password, they'll give up on it and focus on the easier ones to crack. But if their password
hashes also comes with account names (often email addresses), then they can try accessing lots
of other websites with that email/password combo, which is why it's dangerous to reuse your
passwords.
It was
well-understood by the mid 1980's that the 12-bit salting scheme was breakable with existing
hardware. That is why everyone quietly moved to larger salts during that time period.
With reasonable coding assumptions it was possible to crack most any password in 3-5 days on
an early 68k box (e.g. Masscomp or Codata). No, I don't have the code any longer.
My understanding is that Morris modified DES for use in passwd(5) so that you couldn't use
hardware DES to brute-force decrypt passwords.
Unfortunately I suspect he introduced a
vulnerability because apparently the hash leaked information about the key, and since the
high-order bits of a DES key are parity bits you could use that as a prybar to narrow your
search space.
Security
really wasn't at a high premium back then. The need was also less. You might have a prankster
get into your account for a practical joke, but those pranksters probably had root access
anyway. The computer wasn't being used for financial transactions or anything like it; the most
expensive thing you could do was swipe a copy of AT&T Unix.
Back in the '70s on the Univac 1100/80, my password as zxcv. That was at work --
professional environment, no internet, no dialup, so the only threats would be internal.
And when my boss decided to play a practical joke on my account, he just used the Univac
equivalent of root access. As did I, with my retaliation.
Most of those passwords were good enough for their time and place. The kind of brute force
computation that the researchers used would have been prohibitively expensive back then. The
passwords were not protecting anything of great value so there was little incentive to crack
them. (Some of the code those people were working on later came to be quite valuable, but it
was not perceived as having monetary value at the time.) Unless you had access to one of the
relatively few ARPANET sites, you would have needed physical access to the computers to attempt
to crack them.
Posted by msmash on Friday August 16, 2019 @12:45PM
A new
Google study this week
confirmed the obvious:
internet users need to stop using the same password for multiple websites unless they're
keen on having their data hijacked, their identity stolen, or worse. From a report: It seems
like not a day goes by without a major company being hacked or leaving user email addresses and
passwords exposed to the public internet. These login credentials are then routinely used by
hackers to hijack your accounts, a threat that's largely mitigated by using a password manager
and unique password for each site you visit. Sites like "have I been pwned?" can help users
track if their data has been exposed, and whether they need to worry about their credentials
bouncing around the dark web. But it's still a confusing process for many users unsure of which
passwords need updating.
To that end, last February Google unveiled a
new experimental Password Checkup extension for Chrome . The extension warns you any time
you log into a website using one of over 4 billion publicly-accessible usernames and passwords
that have been previously exposed by a major hack or breach, and prompts you to change your
password when necessary. The extension was built in concert with cryptography experts at
Stanford University to ensure that Google never learns your usernames or passwords, the company
says in an explainer. Anonymous telemetry data culled from the extension has provided Google
with some interesting information on how widespread the practice of account hijacking and
non-unique passwords really is.
How to Lock User Accounts After Consecutive Failed Authentications
You can configure the above functionality in the /etc/pam.d/system-auth and
/etc/pam.d/password-auth files, by adding the entries below to the auth
section.
Now open these two files with your choice of editor.
# vi /etc/pam.d/system-auth
# vi /etc/pam.d/password-auth
The default entries in auth section both files looks like this.
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_fprintd.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 1000 quiet
auth required pam_deny.so
After adding the above settings, it should appear as follows.
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth required pam_faillock.so preauth silent audit deny=3 unlock_time=300
auth sufficient pam_fprintd.so
auth sufficient pam_unix.so nullok try_first_pass
auth [default=die] pam_faillock.so authfail audit deny=3 unlock_time=300
auth requisite pam_succeed_if.so uid >= 1000 quiet
auth required pam_deny.so
Then add the following highlighted entry to the account section in both of the above
files.
Once you have configured everything. You can restart remote access services like sshd , for
the above policy to take effect that is if users will employ ssh to connect to the server.
From the above settings, we configured the system to lock a user's account after failed
authentication attempts.
In this scenario, the user tecmint is trying to switch to user
aaronkilik , but after incorrect logins because of a wrong password, indicated by
the " Permission denied " message, the user aaronkilik's account is locked as shown by "
authentication failure " message from the fourth attempt.
Test User Failed Login Attempts
The root user is also notified of the failed login attempts on the system, as shown in the
screen shot below.
Failed Login Attempts Message How to View Failed Authentication Attempts
You can see all failed authentication logs using the faillock utility, which is used to
display and modify the authentication failure log.
You can view failed login attempts for a particular user like this.
# faillock --user aaronkilik
View User Failed Login Attempts
To view all unsuccessful login attempts, run faillock without any argument like so:
# faillock
To clear a user's authentication failure logs, run this command.
# faillock --user aaronkilik --reset
OR
# fail --reset #clears all authentication failure records
Lastly, to tell the system not to lock a user or user's accounts after several unsuccessful
login attempts, add the entry marked in red color, just above where pam_faillock is first
called under the auth section in both files ( /etc/pam.d/system-auth and
/etc/pam.d/password-auth ) as follows.
Simply add full colon separated usernames to the option user in
Looks like pseudo-science. When the number of attempts is limited to five or seven AI is of
little or no help... Only when password files (let's say shadow file) is stolen, then those
methods might be deployed effectively. If the number of attempts to decode password is
unlimited then you definitely can use heuristic strategies to limit the space in which
you generate probes, such as "style" of password selection from previous stolen archives for the
same user.
Researchers at the Stevens Institute of Technology used artificial intelligence to generate
a program that successfully guessed 27 percent of the passwords from more than 43 million
LinkedIn profiles. The team employed a generative adversarial network (GAN), PassGAN, featuring
two artificial neural networks -- a "generator" that produces artificial outputs resembling real
examples, and a "discriminator" that attempts to differentiate real from false examples.
New
York University's Martin Arjovsky says the work "confirms that there are clear, important
problems where applying simple machine-learning solutions can bring a crucial advantage."
However, Cornell Tech's Thomas Ristenpart says this same GAN-based methodology could be applied
to help users and enterprises rate password strength, as well as "potentially be used to
generate decoy passwords to help detect breaches."
Meanwhile, Stevens' Giuseppe Ateniese says
PassGAN can invent passwords indefinitely, noting, "if you give enough data to PassGAN, it will
be able to come up with rules that humans cannot think about."
Posted by BeauHD on Tuesday
December 13, 2016 @06:30PM from the auto-correct dept.
tomhath quotes a report from The Hill:
Last March, Podesta received an email purportedly from Google
saying hackers had tried to infiltrate his Gmail account
. When an aide emailed the campaign's
IT staff to ask if the notice was real, Clinton campaign aide Charles Delavan replied that it was
"a legitimate email" and that Podesta should "change his password immediately."
Instead of telling
the aide that the email was a threat and that a good response would be to change his password directly
through Google's website, he had inadvertently told the aide to click on the fraudulent email and
give the attackers access to the account.
Delavan
told The New York Times
he had intended to type "illegitimate," a typo he still has not forgiven
himself for making.
The email was a phishing scam that ultimately revealed Podesta's password to
hackers.
Soon after, WikiLeaks began releasing 10 years of his emails.
"... After more than two years of public implementation and internal study, Google security architects have declared Security Keys their preferred form of two-factor authentication. ..."
Ars
Technica reports that U2F keys "may be the world's best hope against
account takeovers":
"The Security Keys are based on
Universal Second
Factor
, an open standard that's easy for end users to use and
straightforward for engineers to stitch into hardware and websites. When
plugged into a standard USB port, the keys provide a 'cryptographic assertion'
that's just about impossible for attackers to guess or phish. Accounts can
require that cryptographic key in addition to a normal user password when users
log in. Google, Dropbox, GitHub, and other sites have already implemented the
standard into their platforms.
After more than two years of public
implementation and internal study, Google security architects have declared
Security Keys their preferred form of two-factor authentication.
The architects
based their assessment on the ease of using and deploying keys, the security it
provided against phishing and other types of password attacks, and the lack of
privacy trade-offs that accompany some other forms of two-factor
authentication."
"We have shipped support for Security Keys in the Chrome browser,
have deployed it within Google's internal sign-in system, and have enabled
Security Keys as an available second factor in Google's Web services.
In this
work, we demonstrate that Security Keys lead to both an increased level of
security and user satisfaction as well as cheaper support cost."
"... WikiLeaks series on deals involving Hillary Clinton campaign Chairman John Podesta. Mr Podesta is a long-term associate of
the Clintons and was President Bill Clinton's Chief of Staff from 1998 until 2001. Mr Podesta also owns the Podesta Group with his brother
Tony, a major lobbying firm and is the Chair of the Center for American Progress (CAP), a Washington DC-based think tank. ..."
"... if President Obama signs this terrible legislation that blatantly validates Bernie's entire campaign message about Wall Street
running our government, this will give Bernie a huge boost and 10,000 -20,000 outraged citizens (who WILL turn up because they will
be so angry at the President for preemption vt) will be marching on the Mall with Bernie as their keynote speaker. " ..."
"... But Hirshberg does not stop here. In order to persuade Podesta about the seriousness of the matter, he claims that " It will
be terrible to hand Sanders this advantage at such a fragile time when we really need to save our $$$ for the Trump fight. " ..."
WikiLeaks series on deals involving Hillary Clinton campaign Chairman John Podesta. Mr Podesta is a long-term associate of the
Clintons and was President Bill Clinton's Chief of Staff from 1998 until 2001. Mr Podesta also owns the Podesta Group with his brother
Tony, a major lobbying firm and is the Chair of the Center for American Progress (CAP), a Washington DC-based think tank.
Hirshberg writes to a familiar person, as he was mentioned at the time as a possible 2008 Democratic candidate for the U.S. Senate,
requesting Obama should not pass the Roberts bill because " if President Obama signs this terrible legislation that blatantly
validates Bernie's entire campaign message about Wall Street running our government, this will give Bernie a huge boost and 10,000
-20,000 outraged citizens (who WILL turn up because they will be so angry at the President for preemption vt) will be marching on
the Mall with Bernie as their keynote speaker. "
But Hirshberg does not stop here. In order to persuade Podesta about the seriousness of the matter, he claims that " It will
be terrible to hand Sanders this advantage at such a fragile time when we really need to save our $$$ for the Trump fight. "
"... The emails currently roiling the US presidential campaign are part of some unknown digital collection amassed by the troublesome
Anthony Weiner, but if your purpose is to understand the clique of people who dominate Washington today, the emails that really matter
are the ones being slowly released by WikiLeaks from the hacked account of Hillary Clinton's campaign chair John Podesta. ..."
The emails currently roiling the US presidential campaign are part of some unknown digital collection amassed by the troublesome
Anthony Weiner, but if your purpose is to understand the clique of people who dominate Washington today, the emails that really matter
are the ones being slowly released by WikiLeaks from the hacked account of Hillary Clinton's campaign chair John Podesta. They
are last week's scandal in a year running over with scandals, but in truth their significance goes far beyond mere scandal: they
are a window into the soul of the Democratic party and into the dreams and thoughts of the class to whom the party answers.
The class to which I refer is not rising in angry protest; they are by and large pretty satisfied, pretty contented. Nobody takes
road trips to exotic West Virginia to see what the members of this class looks like or how they live; on the contrary, they are the
ones for whom such stories are written. This bunch doesn't have to make do with a comb-over TV mountebank for a leader; for this
class, the choices are always pretty good, and this year they happen to be excellent.
They are the comfortable and well-educated mainstay of our modern Democratic party. They are also the grandees of our national
media; the architects of our software; the designers of our streets; the high officials of our banking system; the authors of just
about every plan to fix social security or fine-tune the Middle East with precision droning. They are, they think, not a class at
all but rather the enlightened ones, the people who must be answered to but who need never explain themselves.
REPORTERS RSVP (28) 1. ABC – Liz Kreutz 2. AP – Julie Pace 3. AP - Ken Thomas 4. AP - Lisa Lerer 5. Bloomberg - Jennifer Epstein
6. Buzzfeed - Ruby Cramer 7. CBS – Steve Chagaris 8. CNBC - John Harwood 9. CNN - Dan Merica 10. Huffington Post - Amanda Terkel
11. LAT - Evan Handler 12. McClatchy - Anita Kumar 13. MSNBC - Alex Seitz-Wald 14. National Journal - Emily Schultheis 15. NBC
– Mark Murray 16. NPR - Mara Liassion 17. NPR – Tamara Keith 18. NYT - Amy Chozik 19. NYT - Maggie Haberman 20. Politico - Annie
Karni 21. Politico - Gabe Debenedetti 22. Politico - Glenn Thrush 23. Reuters - Amanda Becker 24. Washington Post - Anne Gearan
25. Washington Post – Phil Rucker 26. WSJ - Colleen McCain Nelson 27. WSJ - Laura Meckler 28. WSJ - Peter Nicholas
Pigeon •Nov 3, 2016 9:49 AM
It bothers me these stories are constantly prefaced with the idea that Wikileaks is saving Trump's bacon. Hillary wouldn't
even be close if the press weren't in the tank for her. How about Wikileaks evening the playing field with REAL STORIES AND
FACTS?
Briefly, it seems Podesta received an email "You need to change your password", asked for professional advice from his
staff if it was legit, was told "Yes, you DO need to change your password", but then clicked on the link in the original email,
which was sent him with malicious intent, as he suspected at first and then was inappropriately reassured about - rather than
on the link sent him by the IT staffer.
Result - the "phishing" email got his password info, and the world now gets to see all his emails.
Personally, my hope is that Huma and HRC will be pardoned for all their crimes, by Obama, before he leaves office.
Then I hope that Huma's divorce will go through, and that once Hillary is sworn in she will at last be courageous enough to
divorce Bill (who actually performed the Huma-Anthony Weiner nuptials - you don't have to make these things up).
Then it could happen that the first same-sex marriage will be performed in the White House, probably by the minister of DC's
Foundry United Methodist Church, which has a policy of LBGQT equality. Or maybe Hillary, cautious and middle-of-the-road as usual,
will go to Foundry UMC sanctuary for the ceremony, recognizing that some Americans' sensibilities would be offended by having
the rite in the White House.
As Nobel Laureate Bob Dylan wrote, "Love is all there is, it makes the world go round, love and only love, it can't be denied.
No matter what you think about it, you just can't live without it, take a tip from one who's tried."
In the aftermath of one of the most memorable (c)october shocks in presidential campaign history, Wikileaks continues its ongoing
broadside attack against the Clinton campaign with the relentless Podesta dump, by unveiling another 596 emails in the latest Part
22 of its Podesta release, bringing the total emails released so far to exactly 36,190, leaving less than 30% of the total dump left
to go.
As usual we will go parse through the disclosure and bring you some of the more notable ones.
* * *
In a February 2012 email from Chelsea Clinton's
NYU alias, [email protected], to Podesta and Mills, Bill and Hillary's frustrated
daughter once again points out the "frustration and confusion" among Clinton Foundation clients in the aftermath of the previously
noted scandals plaguing the Clinton consultancy, Teneo:
Over the past few days a few people from the Foundation have reached out to me frustrated or upset about _____ (fill in the
blank largely derived meetings Friday or Monday). I've responded to all w/ essentially the following (ie disintermediating myself,
again, emphatically) below. I also called my Dad last night to tell him of my explicit non-involvement and pushing all back to
you both and to him as I think that is indeed the right answer. Thanks
Sample: Please share any and all concerns, with examples, without pulling punches, with John and Cheryl as appropriate and
also if you feel very strongly with my Dad directly. Transitions are always challenging and to get to the right answer its critical
that voices are heard and understood, and in the most direct way - ie to them without intermediation. Particularly in an effort
to move more toward a professionalism and efficiency at the Foundation and for my father - and they're the decision-makers, my
Dad most of all
I have moved all the sussman money from unity '09 to cap and am reviewing the others . I will assess it and keep you informed
Something else for the DOJ to look into after the elections, perhaps?
* * *
And then there is this email from August 2015
in which German politician Michael Werz advises John Podesta that Turkish president Erdogan "is making substantial investments in
U.S. to counter opposition (CHP, Kurds, Gulenists etc.) outreach to policymakers" and the US Government.
John, heard this second hand but more than once. Seems Erdogan faction is making substantial investments in U.S. to counter
opposition (CHP, Kurds, Gulenists etc.) outreach to policymakers and USG. Am told that the Erdogan crew also tries to make inroads
via donations to Democratic candidates, including yours. Two names that you should be aware of are *Mehmet Celebi* and *Ali Cinar*.
Happy to elaborate on the phone, provided you are not shopping at the liquor store.
This should perhaps explain why the US has so far done absolutely nothing to halt Erdogan's unprecedented crackdown on "coup plotters"
which has seen as many as 100,000 workers lose their jobs, be arrested, or otherwise removed from Erdogan's political opposition.
"... The simplest explanation is usually best. All the indicators, especially the support of the donor class, elites of all kinds
etc. points towards a Democratic victory, perhaps a very strong victory if the poll numbers last weekend translate into electoral college
numbers. ..."
I stopped by to check if my comment had cleared moderation. What follows is a more thorough examination (not my own, entirely)
on Corey's point 1, and some data that may point towards a much narrower race than we're led to believe.
The leaked emails from one Democratic super-pac, the over-sampling I cited at zerohedge (@13o) is part of a two-step process
involving over-sampling of Democrats in polls combined with high frequency polling. The point being to encourage media
to promote the idea that the race is already over. We saw quite a bit of this last weekend. Let's say the leaked emails are reliable.
This suggests to me two things: first – the obvious, the race is much closer than the polls indicated, certainly the poll cited
by Corey in the OP. Corey questioned the validity of this poll, at least obliquely. Second, at least one super-pac working with
the campaign sees the need to depress Trump turn-out. The first point is the clearest and the most important – the polls, some
at least, are intentionally tilted to support a 'Hillary wins easily' narrative. The second allows for some possibly useful speculation
regarding the Clinton campaigns confidence in their own GOTV success.
The simplest explanation is usually best. All the indicators, especially the support of the donor class, elites of all
kinds etc. points towards a Democratic victory, perhaps a very strong victory if the poll numbers last weekend translate into
electoral college numbers.
That's a big if. I suggest Hillary continues to lead but by much smaller margins in key states. It's also useful to
point out that Trump's support in traditionally GOP states may well be equally shaky.
And that really is it from me on this topic barring a double digit swing to Hillary in the LA Times poll that has the race
at dead even.
Layman 10.25.16 at 11:31 am
kidneystones:
"The leaked emails from one Democratic super-pac, the over-sampling I cited at zerohedge (@13o) is part of a two-step
process involving over-sampling of Democrats in polls combined with high frequency polling."
Excellent analysis, only the email in question is eight years old. And it refers to a request for internal polling done by
the campaign. And it suggests over-sampling of particular demographics so the campaign could better assess attitudes among those
demographics.
And this is a completely normal practice which has nothing to do with the polling carried out by independent third parties
(e.g. Gallup, Ipsos, etc) for the purposes of gauging and reporting to the public the state of the race.
And when pollsters to over-sample, the over-sampling is used for analysis but is not reflected in the top-line poll results.
"... Among the initial emails to stand out is this extensive exchange showing just how intimiately the narrative of Hillary's server
had been coached. The following September 2015 email exchange between Podesta and Nick Merrill, framed the "core language" to be used
in response to questions Clinton could be asked about her email server, and the decision to "bleach" emails from it. The emails contain
long and short versions of responses for Clinton. ..."
The daily dump continues. In the now traditional daily routine, one which forces the Clinton campaign to resort to ever more stark
sexual scandals involving Trump to provide a media distraction, moments ago Wikileaks released yet another 1,803 emails in Part 12
of its ongoing Podesta Email dump, which brings the total number of released emails to 18,953.
As a reminder among the most recent revelations we got further insights into Hillary's desire to see Obamacare "
unravel" , her contempt
for "doofus" Bernie Sanders, staff exchanges on handling media queries about Clinton "flip-flopping" on gay marriage, galvanizing
Latino support and locking down Clinton's healthcare policy. Just as notable has been the ongoing revelation of just how "captured"
the so-called independent press has been in its "off the record" discussions with John Podesta which got the head Politico correspondent,
Glenn Thrush, to admit he is a "hack" for allowing Podesta to dictate the content of his article.
The release comes on the day of the third and final presidential campaign between Hillary Clinton and Donald Trump, and as a result
we are confident it will be scrutinized especially carefully for any last minute clues that would allow Trump to lob a much needed
Hail Mary to boost his standing in the polls.
As there is a total of 50,000 emails, Wikileaks will keep the media busy over the next three weeks until the elections with another
30,000 emails still expected to be released.
* * *
Among the initial emails to stand out is this extensive exchange showing just how intimiately the narrative of Hillary's server
had been coached. The following September 2015 email
exchange between Podesta and Nick Merrill, framed the "core language" to be used in response to questions Clinton could be asked
about her email server, and the decision to "bleach" emails from it. The emails contain long and short versions of responses for
Clinton.
"Because the government already had everything that was work-related, and my personal emails were just that – personal – I
didn't see a reason to keep them so I asked that they be deleted, and that's what the company that managed my server did. And
we notified Congress of that back in March"
She was then presented with the following hypothetical scenario:
* "Why won't you say whether you wiped it?"
"After we went through the process to determine what was work related and what was not and provided the work related
emails to State, I decided not to keep the personal ones."
"We saved the work-related ones on a thumb drive that is now with the Department of Justice. And as I said in March, I chose
not to keep the personal ones. I asked that they be deleted, how that happened was up to the company that managed the server.
And they are cooperating fully with anyone that has questions."
* * *
Another notable email reveals the close
relationship between the Clinton Foundation and Ukraine billionaire Victor Pinchuk, a
prominent
donor to the Clinton Foundation , in which we see the latter's attempt to get a meeting with Bill Clinton to show support for
Ukraine:
From: Tina Flournoy < [email protected]>
Sent: Monday, March 30, 2015 9:58:55 AM
To: Amitabh Desai
Cc: Jon Davidson; Margaret Steenburg; Jake Sullivan; Dan Schwerin; Huma Abedin; John Podesta
Subject: Re: Victor Pinchuk
Team HRC - we'll get back to you on this
> On Mar 30, 2015, at 9:53 AM, Amitabh Desai < [email protected]> wrote:
>
> Victor Pinchuk is relentlessly following up (including this morning) about a meeting with WJC in London or anywhere in Europe.
Ideally he wants to bring together a few western leaders to show support for Ukraine, with WJC probably their most important participant.
If that's not palatable for us, then he'd like a bilat with WJC.
>
> If it's not next week, that's fine, but he wants a date. I keep saying we have no Europe plans, although we do have those events
in London in June. Are folks comfortable offering Victor a private meeting on one of those dates? At this point I get
the impression that although I keep saying WJC cares about Ukraine, Pinchuk feels like WJC hasn't taken enough action to demonstrate
that, particularly during this existential moment for the county and for him.
>
> I sense this is so important because Pinchuk is under Putin's heel right now, feeling a great degree of pressure and pain for
his many years of nurturing stronger ties with the West.
>
> I get all the downsides and share the concerns. I am happy to go back and say no. It would just be good to
know what WJC (and HRC and you all) would like to do, because this will likely impact the future of this relationship, and slow
walking our reply will only reinforce his growing angst.
>
> Thanks, and sorry for the glum note on a Monday morning...
Sure. Sorry for the delay I was on a plane.
On Apr 30, 2015 9:44 AM, "Glenn Thrush" < [email protected]> wrote:
> Can I send u a couple of grafs, OTR, to make sure I'm not fucking
> anything up?
* * *
Another notable moment emerges in the emails, involving Hillary Clinton's selective memory. Clinton's description of herself as
a moderate Democrat at a September 2015 event in Ohio caused an uproar amongst her team. In a
mail from Clinton advisor Neera Tanden to Podesta
in the days following the comment she asks why she said this.
"I pushed her on this on Sunday night. She claims she didn't remember saying it. Not sure I believe her," Podesta replies.
Tanden insists that the comment has made her job more difficult after "telling every reporter I know she's actually progressive".
" It worries me more that she doesn't seem to know what planet we are all living in at the moment ," she adds.
* * *
We also get additional insight into Clinton courting the Latino minority. A November 2008
email from Federico Peña , who was on the Obama-Biden
transition team, called for a "Latino media person" to be added to the list of staff to appeal to Latino voters. Federico de Jesus
or Vince Casillas are seen as ideal candidates, both of whom were working in the Chicago operations.
"More importantly, it would helpful (sic) to Barack to do pro-active outreach to Latino media across the country to get our
positive message out before people start spreading negative rumors," Peña writes.
* * *
Another email between Clinton's foreign policy adviser
Jake Sullivan and Tanden from March 2016 discussed how it was "REALLY dicey territory" for Clinton to comment on strengthening
"bribery laws to ensure that politicians don't change legislation for political donations." Tanden agrees with Sullivan:
" She may be so tainted she's really vulnerable - if so, maybe a message of I've seen how this sausage is
made, it needs to stop, I'm going to stop it will actually work."
* * *
One email suggested, sarcastically, to kneecap
bernie Sanders : Clinton's team issued advise regarding her tactics for the "make or break" Democratic presidential debate with
Sanders in Milwaukee on February 11, 2016. The mail to Podesta came from Philip Munger, a Democratic Party donor. He sent the mail
using an encrypted anonymous email service.
"She's going to have to kneecap him. She is going to have to take him down from his morally superior perch. She has done so
tentatively. She must go further," he says.
Clearly, the desire to get Sanders' supporters was a key imperative for the Clinton campaign. In a
September 2015 email to Podesta , Hill columnist
Brent Budowsky criticized the campaign for allegedly giving Clinton surrogates talking points to attack Bernie Sanders. "I cannot
think of anything more stupid and self-destructive for a campaign to do," he says. "Especially for a candidate who has dangerously
low levels of public trust," and in light of Sanders' campaign being based on "cleaning up politics."
Budowsky warns voters would be "disgusted" by attacks against Sanders and says he wouldn't discourage Podesta from sharing the
note with Clinton because "if she wants to become president she needs to understand the point I am making with crystal clarity."
"Make love to Bernie and his idealistic supporters, and co-opt as many of his progressive issues as possible."
Budowsky then adds that he was at a Washington university where " not one student gave enough of a damn for Hillary to
open a booth, or even wear a Hillary button. "
* * *
One email focused on how to address with the
topic of the TPP. National Policy Director for Hillary for America Amanda Renteria explains, "The goal here was to minimize our vulnerability
to the authenticity attack and not piss off the WH any more than necessary."
Democratic pollster Joel Benenson says, "the reality is HRC is more pro trade than anti and trying to turn her into something
she is not could reinforce our negative [sic] around authenticity. This is an agreement that she pushed for and largely advocated
for."
* * *
While claiming she is part of the people, an email exposes Hillary as being "
part of the system ." Clinton's team acknowledges
she is "part of the system" in an email regarding her strategies. As Stan Greenberg told Podesta:
" We are also going to test some messages that include acknowledgement of being part of the system, and know how much
has to change ,"
* * *
Some more on the topic of Hillary being extensively coached and all her words rehearsed, we find an email which reveals that
Clinton's words have to be tightly managed by her
team who are wary of what she might say. After the Iowa Democratic Party's presidential debate in November 2015 adviser Ron Klain
mails Podesta to say, "If she says something three times as an aside during practice (Wall Street supports me due to 9/11), we need
to assume she will say it in the debate, and tell her not to do so." Klain's mail reveals Sanders was their biggest fear in the debate.
"The only thing that would have been awful – a Sanders break out – didn't happen. So all in all, we were fine," he says.
The mail also reveals Klain's role in securing his daughter Hannah a position on Clinton's team. "I'm not asking anyone to make
a job, or put her in some place where she isn't wanted – it just needs a nudge over the finish line," Klain says. Hannah Klain worked
on Clinton's Surrogates team for nine months commencing in the month after her father's mail to Podesta, according to her Linkedin.
I love this...Assange is incommunicado, yet the data dumps keep coming!
Horse face looks like such a fool to the world as a result; & due to John Kerry's stupidity which is drawing major attention to
the whole matter; Americans are finally beginning to wake up & pay attention to this shit!
Looks like the Hitlery for Prez ship is starting to take on MASSIVE amounts of water!
I believe they are beyond the point where any more news of 'pussy grabbing' will save them from themselves (and Mr. Assange)!
The new lowered expectations federal government just expects to get lucre + bennies for sitting on their asses and holding
the door for gangsters. Traitors. Spies. Enemies foreign and domestic. Amphisbaegenic pot boiling.
With Creamer's tricks effective in Obama's re-election, it now makes sense why Obama was so confident when he said Trump would
never be president.
Trump is still ahead in the only poll I track. But i conduct my own personal poll on a daily basis and loads of Trump supporters
are in the closet and won't come out until they pull the lever for Trump on election day.
And here is the resource LeakedSource analyzed these same 100
million stolen accounts "Vkontakte". Half a million out of a hundred use passwords obtained by pressing
the number keys in the top row of a computer keyboard from left to right. One of the password 123456
more than 700 thousand thousands 300 press left-right keys of the second row of the keyboard from
qwerty to continue. Then there are passwords that are composed of repetitions of the same figures,
and the most popular sevens and ones. The Morris, of course, was still the most popular passwords
of the network administrators of the ARPANET: the word admin. But the users of the network "Vkontakte"
this word is not in use. But they know the word password is the fourth and last necessary word in
the modern dictionary to guess passwords. The rest is a combination of both.
Well, here you have the problem of defense against idiots. When
the idiot is the owner of the account. Who never read about Snowden (and probably never read any
book for a while). All those methods of improving password security that were invented for over thirty
years for people to improve security of password authentication, proved to be to most users unnecessary.
Of course, the situation is gradually changing. Currently, the
percentage of complex passwords has become much higher than before. But this situation is changing
due to the growth of awareness of users, but due to the tough measures undertaken by the cloud services
providers. They are forced to change passwords, forced to come up with complex passwords, dontianing
digits, delimiters and upper case letters, they introduces two-factor authentication with tokens,
SMS and captcha based suffixes.
... ... ...
The situation is similar in other areas. All people on this planet
know that smoking is harmful. They all know it's dangers of reckless driving and driving under influence.
And certainly know that unprotected promiscuous sex can lean to STD infection. The state always tries
to protect people from these stupid things, restricts the sale of tobacco, introduces penalties for
dangerous driving and promote family values.
However, some people do it anyway. And get HIV, die from lung
cancer, and ger injuded in an accident (and injuse and kill others). they just do not care about
such consequences. And when these some females open accounts with password 123456, where immediately
post their naked pictures, they for sure do not care about the consequences. That's just their nature.
And such behaviour is not limited to social networks
Professor Columbia University Steven Bellovin three years ago,
said that for 20 years the presidential code for launching missiles "Minuteman" with nuclear warheads
was unchanged and represented, attention,... a sequence of eight zeros!
There are times when you will want a single purpose user account – an account that cannot get
a shell, not can it do anything but run a single command. This can come in useful for a few reasons
– for me, I use it to force an svn update on machines that can't use user generated crontabs. Others
have used this setup to allow multiple users run some arbitrary command, without giving them shell
access.
Add the user
Add the user as you'd add any user. You'll need a home directory, as I want to use ssh keys so
I don't need a password and it can be scripted from the master server.
root@slave1# adduser restricteduser
Set the users password
Select a nice strong password. I like using $pwgen 32
root@slave1# passwd restricteduser
Copy your ssh-key to the server
Some Linux distros don't have the following command, in this case, contact your distro mailing
list or Google.
root@master# ssh-copy-id restricteduser@slave1
Lock out the user
Password lock out the user. This contradicts the above step, but it ensures that restricteduser
can't update their password.
root@slave1# passwd -l restricteduser
Edit the sshd config
Depending on your system, this can be in a number of places. On Debian, it's in /etc/ssh/sshd_config.
Put it down the bottom.
Match User restricteduser
AllowTCPForwarding no
X11Forwarding no
ForceCommand /bin/foobar_command
Restart ssh
root@slave1# service ssh restart
Add more ssh keys
Add any additional ssh key to /home/restricteduser/.ssh/authorized_keys
Better financial sites now allow two factor authentication. Often using your cellphone
as the "second factor by sending message to it). Also most financial sites now use "pre-authentication"
for any "new" IP: they first ask set of predefined questions about account owner history (maiden name
of your mother, name of High School that you attended, brand of your first car, etc). Using some combination
of those words actually makes sense in passwords too. But as the article below suggests there are other
useful way to increase length of the password without making it more difficult to remember.
Most tips for picking a strong password make it harder, not easier. These tips make it easier.
Like a lot of people, I cycle through a small collection of passwords that I have been using for
a decade or more. This is not the greatest security practice, I admit, but the world is so riddled
with requests to log-in in different places and so many of them are so not very important (did you
hack my IMGUR account? Oh gee! Did you post something I didn't really say on that Star Wars
newsgroup? Heavens!). Security is important, but I get
where the guy who posted all his passwords online is coming from.
That said, we understand poorly how vulnerable we are, as
two nice guy hackers recently demonstrated to a volunteer grandmother who thought she was too
off-line to get hacked. Incorrect.
Err on the side of security. I make passwords that will crush your puny decryption programs, and
here's the truth: it's not hard. Most of the advice out there isn't very helpful, though. It makes
coming up with passwords sound complicated. "Use four upper-case letters with three lower-case following
them and symbols on every third Tuesday." Amirite?
That's intimidating. My tips get you there much more easily.
You have information in your head that easily converts to really strong passwords. You just need
to look in the right places.
Here's some examples of stuff you know already that easily converts to strong passwords that you
can remember (because you've known it for years):
Addresses. Most modern people move homes and move jobs and therefore have
a bunch of old addresses in their heads. Addresses make for very robust passwords (just don't
use your current one, obviously). Try old work addresses or the place you grew up. If
you lived in an apartment, even better. "646 7th Street #203" would make for a great password.
Even better, put two in a row. - [[Note: You old car registration plates
also make a good candidatures -- NNB]]
Song lyrics. This won't work for those problematic services that require
such specific guidelines that they make guessing passwords easier, but lyrics do make for nice
long passwords that are really hard to bust (because
longer passwords are more secure than complex ones). I got this idea from a buddy of mine
that had a Talking Heads lyric from a favorite song as his wifi password. The first line from
one of my favorite Decemberists songs would be pretty decent: "Billy Liar's got his hands
in his pockets." It's even got a symbol in it naturally. --[Note: you
can use first two or three letters from each word -- that's a better deal -- NNB]
Nerd references. We all have our geeky interests and many of them have great
combinations of letters and numbers. Love the Red Sox? How about a password from a great series:
"2007RedSoxIndians4-3." Love Spider-Man? How about his first appearance in comics: "AmazingFantasy#15."
Love movies? Combine a favorite actor with a favorite film:
MichaelJ.FoxBackToTheFuture1985
Old phone numbers. Not your phone number, but one from your past that you
can't forget but that no one else would know. I can remember several phone numbers from my childhood,
none of which are even still in use any more. "Jessica316-231-5703" would make for a
solid password. You won't even find that in my phone, but it's a series of digits I will never
forget. If you don't have a number like that, use an old office number or your parents' number,
combined with their full names.
Important dates combined with places. Your wedding day and your birthday
are no good, but what if you add in some other information? For example, a wedding and a place:
"St.Matthew'sChurch9/14/2011." You could also combine two graduations, such as high school
and college: "ColumbusHigh2000OhioState2004." Those are nice and long, with lots of complexity.
Biographical series.Put chains of basic facts of your life in order.
For example, I could do all the Philadelphia neighborhoods I have lived in: "Fairmount>Fairhill>Newbold."
You could do a string of cars, significant others, cities or pets.
--[[You can also use formulas instead of digit part of your passwrd, for example 2+2=5 ;-) --
NNB ]]
Any of these ideas make for memorable passwords that will protect you better than "12345" or "password."
And while I want to encourage you to use biographical information, ask yourself whether or not
it could be easily discovered by looking at your LinkedIn or Facebook profile. Don't use your
kid's name, your spouse's name, your birthday, your anniversary or your kid's birthdays. Also, apparently
a lot of you
are using "iloveyou." Seriously: how do you live with yourself?
Another helpful property of biographical passwords is that you can write down hints somewhere
in ways that you'll know what you mean, but would still make it hard for an adversary.
Take the last example. Your reminder for an account could be a clue like "Graduations." Someone
might be able to work it out from there if they were really determined, but it would take time.
For really important accounts, though (your bank accounts, Paypal, Google, Apple, etc.), opt-in
to two-factor authentication. Two factor authentication combines your password with some other
piece of information that is sent to you.
Google has an app for it.
Paypal
and banks like to shoot you texts or emails. Apple has built it into its latest operating systems,
but you need to turn it on
(so, turn it on).
I have a confession to make: I once fell for a phishing attack on my Paypal account. I realized
what I'd done it as soon as I finished doing it, but it was too late: The hackers got my password.
As savvy as I am about these things, sometimes you get caught on a bad day, and you do dumb things.
It didn't matter, though. I'd enabled two-factor authentication on my Paypal account. So, when they
did try to get in, they didn't have access to my mobile and couldn't see the code Paypal sent me.
JPMorgan Chase was among five banks that were reported to have been
hacked earlier this year, and details have emerged on how the hack took place.
When news first broke in August, it was believed that a zero-day Web server exploit was used to
break into the bank's network. Now, however, TheNew York Times is
reporting that the entry point was much more mundane: a JPMorgan employee had their credentials
stolen.
This shouldn't have been a problem. JPMorgan uses two-factor authentication, meaning that
a password alone isn't sufficient to log in to a system. Unfortunately, for an unknown reason one
of the bank's servers didn't have this enabled. It allowed logging in with username and password
alone, and this weak point in the bank's defenses was sufficient for hackers to break in and access
more than 90 other servers on the bank's network.
The intrusion lasted several months, starting in spring and only being stopped in mid-August.
Sources briefed on the FBI's investigation of the attack told NYT that customer financial
information wasn't compromised. The ongoing intrusion was only discovered when JPMorgan noticed that
a server used to run the website for its Corporate Challenge charity race had been broken into.
It's unclear why one server was left without two factor authentication enabled, though NYT
notes that JPMorgan's network is a complex agglomeration of numerous legacy systems that have
accumulated over the years as the bank has bought and merged with other banks. This makes managing
and securing the network more difficult than it might otherwise be.
Internet users who are sick of endlessly memorising passwords would be much better off reusing
the same one over and over, according to surprising research published by Microsoft.
Complex, unique passwords should only be used to access highly sensitive data such as a person's
bank account, says the academic paper published by Microsoft Research, the R&D arm of the software
firm. Simpler passwords should then be recycled for low-risk websites, the researchers argue.
... ... ...
The savvy web user should make a list of the websites they regularly visit and divide them
into sensitive and non-sensitive piles, the paper says, devoting as much brainpower as possible
to creating complex passwords for the former and as little as possible to the latter.
... "Despite violating long-standing password guidance, writing passwords down is, if properly
done, increasingly accepted as a coping mechanism," they write.
"Other strategies to cope with the human impossibility of using strong passwords everywhere without
re-use include single sign-on, use of email-based password reset mechanisms, and password managers."
The research was conducted by Dinei Florêncio and Cormac Herley from Microsoft Research and
Paul C. van Oorschot from Carleton University in Canada.
Users will find instructions on how to add a second form
of authentication on the Microsoft
Account settings page. The chief form of secondary authentication
will be a short code sent to the user's mobile phone, the number of which Microsoft
will keep on file, each time the user logs on.
As an alternative to security codes, Microsoft is providing a number of other forms of authentication
as well. For smartphones, users can deploy an authenticator app. Microsoft has released an authenticator
app for Windows Phones, and third-party authenticator apps can be used for other platforms. For those
devices that do not directly support two-factor authentication, such as the Xbox, users can get a
secondary password, one unique to each device.
Few common IT policies drive users to distraction as regularly and reliably as the excessive zeal
in enterprise password policies. In switched environment with limited number of attempts even 6 character
passwords are strong enough for all practical purposes.
arstechnica.com
Few common IT policies drive users to distraction as regularly and reliably as the aggressiveness
of enterprise password policies.
... ... ...
Passwords are still important, but the value of aggressive password policies as security against
unauthorized access is questionable, said Andrew Marshall, CIO of Philadelphia-based
Campus Apartments in an interview
with Ars Technica. "Statistical attacks-repeated attempts at guessing a password using hints or a
dictionary-are unlikely to yield results, provided that the enterprise system implements a 'lockout
after X incorrect attempts" policy," he said. "Enforcing tricky complexity and length rules increases
the likelihood that the password will be written down somewhere."
Even strong passwords don't prevent breaches. Scott Greaux, a product manager at
Phishme, a security risk assessment firm, said that
most recent data breaches have been the result of social engineering attacks like phishing. "Every
major breach has been initiated by phishing," he said. "Password controls are great. Mature authentication
systems enforce strong passwords, and have reasonable lockouts for failed login attempts, so brute-forcing
is increasingly difficult."
But, Greaux says, the weak link is a user's trusting nature. "I could ask people for their strong,
complex password," he added, "and they'll probably give it to me."
If users aren't writing down or giving up their password, many just forget them, increasing the
workload on help desks. Adam Roderick, director of IT services at
Aspenware, tells Ars that he frequently hears
from client companies that a quarter to a third of all help-desk requests are the result of forgotten
passwords or locked accounts. Despite the availability of self-service password recovery systems
such as those from
ManageEngine,
"I do not see much investment from corporate IT in password recovery tools," he said.
Roderick said single sign-on systems could significantly reduce the problem, since users' frustrations
usually come from having to manage multiple passwords.
XKCD always has something interesting and funny to say. This one made me think a bit:
We all know longer is better than more funky, but we rarely do it in practice. I've seen plenty
of passwords in my time and they are almost always 6-8 chars. Why? Least common denominator of course,
the truth is that most people (even IT people) re-use the same password over and over, so they pick
on that works with everything, meaning 8 chars long with an alphanumeric mix.
I remember the first time I used a program that supported and encouraged long passwords… it was
PGP, which called them pass phrases. Frankly, I wish all use of the word "password" was replaced
with "pass phrase" as it instantly changes your perception into something more useful.
Most UNIX systems now use SHA or MD5 has the default scheme, which allows up to 255 chars for
your password. So that's not a limitation anymore. But what about most web sites? I thought I'd use
the model XKCD offers as a test. I created a pass phrase that is simply my 4 favorite things, in
order, with spaces in between and the first char of each word capitalized. No digits, no punctuation.
The 4 words plus spaces comes out to 29 chars. Then I changed my password on some popular sites to
see if it would work. Here are the results:
Facebook: Works
Google (Gmail/Youtube): Works
Twitter: Works, but spaces are not allowed.
Yahoo (Yahoo Mail): Works (See below)
Reddit: Works
Digg: Works
Funny thing happened when I changed my Yahoo password, it switched my language preference to Vietnamesse
for some reason. And, to make it all the more bizarre, there is no obvious place to change my language
preference back. I guess I'll have to use Google Translate to fix my Yahoo account.
So, go ahead, change your password to something easier to remember and more secure, and let go
of your old standby.
PS: If your managing systems… for heavens sake, turn on account locking and consider using
Duo.
[Apr 28, 2010]
'Strong' Passwords May Not Be All They're Cracked Up to Be By
Aaron Weiss
"In today's Internet age, hackers don't need to blindly guess at users' passwords because it is
much easier to steal them."
April 27, 2010 |
www.esecurityplanet.com
A recent headline in a major news outlet
announced, "Please
do not change your password" because, as the sub-head teased, "it's a waste of your time." The
paper cited in the story is the latest salvo questioning a certain orthodoxy about computer security-that
strong, cryptic passwords are the keystone to personal security online. This oft-repeated advice
may be at best, outdated, and at worst, counterproductive, potentially exposing users to more risk
rather than less.
When creating accounts, users are often told to choose "strong" passwords-meaning that they are
of sufficient length (often longer than 6 characters) and include a combination of characters that
do not resemble simple words. The premise, of course, is that these passwords will be difficult for
a hacker to guess. We've all seen the crucial scene in a movie where the evil hacker logs onto a
victim's computer and, using only their wit, guesses the correct password. But like most events in
movies, this hardly ever happens in real life.
In today's Internet age, hackers don't need to blindly guess at users'
passwords because it is much easier to steal them. Take phishing attacks, for example.
An April 2010 study by Symantec found that 17% of all spam messages are phishing attempts, wherein
the user is lured into visiting a decoy site which imitates a site they would normally trust-like
eBay, Paypal, or their bank. The unwitting user attempts to log in to the decoy site by providing
their credentials and voila, they've just handed their password over to the hackers.
Last year, Microsoft's Hotmail service
lost several
thousand user passwords in just this way. Earlier this year, Twitter required many users to
change their passwords
after widespread phishing fraud. And as reported
right here on eSecurityPlanet in April, phishing attacks against eBay collected over 5,000
user passwords.
From the hackers' point of view, phishing is far more effective than password guessing. After
all, it makes no difference how "strong" your password is if you are tricked into giving it away.
Just imagine how long it would have taken hackers to simply guess the tens of thousands of passwords
revealed in just these three attacks.
More pernicious than even phishing are keyloggers, which often wind up on compromised PC's by
way of malware infections. There are
dozens of keylogger programs
which can record every keystroke a user makes. Often installed without the user's knowledge, these
keyloggers can then "phone home" and send the recorded data to the hackers' servers, where it can
be analyzed for logins and passwords. Again, like phishing attacks, password strength is no defense
at all against keyloggers.
Strong passwords are also commonly recommended as a defense against so-called "brute force" or
"dictionary" attacks. In this sort of attack, the hacker is not trying to take an educated guess
at the victim's password. Instead, he or she is using software to try millions of permutations of
common words and numbers, hoping to get a successful hit. Theoretically, a "difficult" password will
take longer for a software algorithm to unlock because it will have to go through more permutations
to hit upon it-but how much longer? Computers are so fast these days, and brute force attacks can
be run over sophisticated distributed networks, meaning that almost no password is safe against a
thorough brute force attack.
The best defense against brute force attacks may not be the password itself, but how the server
storing it is configured. In a paper ("Do
Strong Web Passwords Accomplish Anything?"), Microsoft researchers argue that on the Web, servers
should be designed with sensible lockout policies. Some sites do this already-if you fail to login
three times, your account is temporarily disabled. This is not quite the recommended strategy because
it can unfairly punish users who are legitimately trying to recall their password. Better still,
a lockout policy based on a ratio-say, ten failed logins per hour-would provide a more generous window
for legitimate users yet still block massive brute force attacks. Unless the attacker can attempt
thousands of logins per hour, they have little chance of success.
A variation of the brute force attack is known as the offline attack. In this case, the hacker
somehow obtains password data from the server and runs brute force software against it in the privacy
of their own lair. Clearly, the best defense against an offline attack is to run a secure server
that is not vulnerable to being data-harvested by hackers. Better still is to store passwords in
a format that is extremely resistant to brute force decryption - a
preferred algorithm
combines a randomly-generated salt with a hash key. Such a password cannot be decrypted, and generating
a successful brute force attack against it could take months, if not years, of computing time, a
certain turnoff to hackers.
When users are encouraged or required to create passwords that are very difficult to remember,
they are apt to store them somewhere. This is how strong passwords can actually undermine security-a
strong password stored in an unsecure location could be stolen. As we've seen, stolen passwords are
the far more common means of unauthorized access than passwords being guessed.
To be fair, the conclusion to be drawn from reconsidering password security is probably not that
strong passwords are entirely worthless. The problem is that our conventional wisdom still treats
passwords like a first line of defense when, in fact, in today's security environment, passwords
should really be a last line of defense.
Just released, this prescriptive guide shows IT Pros how to use Microsoft Windows Server 2003
Active Directory for both authentication and identity storage within heterogeneous Microsoft Windows
and UNIX environments.
Microsoft released a pretty big guide on how to do this (make UNIX systems do authentication and
authorization through AD). You can pick up the current version
here.
Microsoft announced at TechEd US that the team which built that guide is revising it to explicitly
support HP-UX 11 (i.e. they're going to test with HP-UX systems, include the exact commands to be
issued there, etc.).
The current guide, called "version 0.9", supports Solaris and RedHat; see the guide itself for
the specific versions tested.
SUMMARY: Solaris login based on Windows Domain?
[Original post at bottom]
Thanks for the input: Debbie Tropiano, Bousquet Francois, Alan Pae,
Chris Pinnock, Victor Schrader, Tristan Ball, Darryl Baker
We now have some new topics and directions to research. The biggest
disappointment was that (according to Chris) Solaris with RADIUS is
not supported yet. Looks like we'll need to dive into LDAP or
Kerberos if we're serious about addressing this issue. Of course
NIS or NIS+ related is possible, but what little NIS I see out
there is slowly disappearing. Below is a collection of the replies
with some additional links at the bottom.
>>>>>It may be more than you want or need, but we use
Ganymede (http://tools.arlut.utexas.edu/gash2/)
here and using it allows up to have logins that
authenticate both for Windows and Solaris. It's
open source, so perhaps it'll give you an idea
of how it's done (no, I don't know the internals).
>>>>>Look for LDAP
I've just installed a Samba PDC with an LDAP backend to connect my Windows
Server and I am using pam_ldap to authenticate Solaris to LDAP.
This creates a centralized authentication for both types of server. The
system is secure with SSL encrypted connections and standard with LDAP.
If you are not using Solaris 7 or minus or Windows NT 4.0 you might also
consider using Sun iPlanet (Sun LDAP server) and get support from Sun for
installation.
>>>>>Although I've never used it, you might want to look into:
http://www.vintela.com/products/vas/ <http://www.vintela.com/products/vas/>
also, I think the Sun Blueprints site might have a doc on this subject.
[ed note: I did find a few docs which are listed further below.]
>>>>>A1: It is possible with Kerberos. Active Directory is Kerberos underneath.
A2: You would need to have login linked against a radius library - possible
on FreeBSD but not on Solaris at the moment.
>>>>>Supposedly (have not done this myself yet), MS has 'Services for Unix' that
will let W2K+ be a NIS master with passwd syncing between the 2 worlds. I
have been using it, but not with NIS (yet). Out of the box (it is free) it
has Korn shell and functions as a NFS server in parallel with CIFS shares. I
have a mixed network of Solaris X86, various Linux versions and Windows
machines the idea seems attractive to me. If you play with it let me know how
it goes.
>>>>>Checkout the windbindd system that is part of samba-3.
You don't need to use samba, the winbindd part hooks in as a NSS
modules.
>>>>>If it is a XP domain you could use the XP server as an LDAP server.
>>>>>Additional information that needs to be digested:
Extending Authentication in Solaris 9 with PAM (part1)
http://www.sun.com/blueprints/0902/816-7669-10.pdf
Extending Authentication in Solaris 9 with PAM (part2)
http://www.sun.com/blueprints/1002/816-7670-10.pdf
Solaris and LDAP naming services
http://www.sun.com/books/catalog/bialaski.xml
[original post follows...]
by Anonymous Coward on Saturday June 02, @08:45PM (#180875)
Hi,
We have had similar issues regarding Microsoft's Active Directory product at Amaa Fui. We were
switching from a Unix based kerberos system to one that used Microsoft's.
Here are some solutions to the same problems you had. Firstly, you need to patch your w2k boxes
to the latest pack. Then install the beta k5 updates from Microsoft beta w2k site. These updates
remove the slight changes Microsoft made to kerberos, and thus makes it compatible with your other
systems.
Once those are patched in, you need to install Heesi optimizer (This can be found on any download
site), I recommend this, cause this would go through your AD configuration and kerberos setup and
tell you exectly where your security is weak and so on.
Once everthing is in place, you can move to more secure passwords and corportation wide access
to single passwords. But let me warn you, you still need different passwords on resources that are
of a criticial nature.
Also ensure everthing is behind firewalls and if your using VPN install the latest patches from
Microsoft site, We run OpenBSD and Ipsec, they work very well with the current configuration.
Our systems include, Windows 2k/nt, Linux i386/alpha/ppc, Mac OS 9/X, HP/UX, IBM AIX, Solaris
and an old VAX system. All of them are maintained by the w2k based kereberos authentication systme
and LDAP for directory stuff.
Everthing works well and I'm very satisfied, only concern we have is that Microsoft's version
of kerberos is very slow to authenticate our user. This creates some problems, specially since some
of our internal services have authentication decay in it, to solve this problem we just moved to
better hardware, but this is something Microsoft has to solve on their own.
Good luck with your setup and hope this helps, if not you can send me an e-mail to, [email protected]
Authenticating users against AD with pam_krb5 works fine. Just
list the DNS names of your Win2k domain controllers in the config file just as if they were normal
Kerberos servers, and use the AD domain as the Kerberos realm.
When I did this, I still had local passwd and group files. But it should be possible to move
that stuff into AD. You would have to modify the AD schema to include that info in the directory
(that's not a task for the faint of heart). Once you do that, though, it's pretty easy to query
AD from Linux.
This procedure assumes that you are using
Windows Server 2003
R2; if you are using a previous version, the LDAP attribute mapping will need to be modified
to match the schema extensions found in Microsoft's Services for Unix (SfU) add-on product.
Solaris OpenLDAP authentication against Active Directory
Hi.
I don't know MS AD specific regarding LDAP implementation (perhaps they have
more or less standard one) but for OpenLDAP I used defaults when building
pam_ldap and nss_ldap.
Both clients and server are Solaris 9.
What sort of problem do you have exactly? Otherwise it is very difficult to
help...
Computer hackers have taken to stealing data the easy way -- by eavesdropping
on phone and e-mail conversations to find the keys to seemingly impregnable networks, security experts
say.
The danger of attacks with insider information was illustrated earlier
this month with the arrest of a California man accused of breaking into mobile phone network T-Mobile
USA Inc.'s database and reading e-mails and files of the U.S. Secret Service, and by the exploits
of a hacker who breached a hospital's database and changed mammogram results.
The nature of threats to network security has changed as sophisticated
hackers learned to tap into sensitive information flowing through telecommunications servers, especially
those that provide wireless and Internet access.
"Telecom providers are probably one of the main targets for malicious
attackers because they control communications for everybody," said Ralph Echemendia, head of Intense
School, which trains executives in network security risks.
Hackers may con their way into a phone network by posing as phone
company tech employees to get passwords into the network. Then they could essentially tap phones
or search for personal data like text files or even camera phone photos.
"[Hackers] will sit there and listen in, waiting to get valuable information,"
Echemendia said. "Once they have a foothold on one system, they go through the same process to find
other hosts."
Security experts at Intrusic Inc. captured 4,466 passwords and 103
master passwords allowing global access to corporate databases while monitoring just one Internet
service provider for a 24-hour period, Intrusic President Jonathan Bingham said. "It's like stealing
candy from a baby," he said. "The malicious attacker will assume the identity of a person whose password
they have stolen through this passive sniffing, and they end up entering this organization as a legitimate
user."
Once inside, it takes the hacker seconds to set up back doors that
allow access to the database at any time to do more spying, data theft or worse.
Most hackers, however, are after information -- passwords, Social
Security numbers and birth dates -- that they can sell or use to penetrate bank and credit card accounts,
Forrester Research Inc. analyst Laura Koetzle said.
"Telecoms and cable companies are pretty high on the list simply because
of their huge customer bases," Koetzle said. "If they can crack T-Mobile's database, they can get
user names and passwords for [millions of] subscribers at all once."
In a statement, T-Mobile, a Deutsche Telekom AG unit, said that it
"quickly put in safeguards to prevent further access and began an investigation" after a hacker broke
into its internal computer systems in 2003 and accessed data on 400 customers.
As more companies shift business functions to the Internet and allow
workers to access secure systems from off-site, it becomes tougher to guard against insider attacks
and easier for hackers to breach the systems, said Stan Quintana, director of managed security services
at AT&T Corp. "All these types of environments are requiring a higher level of security ... of data
in transit," he said.
The key to reducing damage from inevitable insider attacks is to constantly
monitor data flow and train employees to guard passwords and access to computers, he said. Among
the best practices AT&T advocates is that its customers periodically hack into their own networks,
he said.
Reduce risks and eliminate headaches through sensible account management
Cameron Laird ([email protected])
Vice president, Phaseit, Inc. 9 October 2002
Security is a big, challenging topic, but everyone with server-side responsibilities should know
the basic steps. Cameron outlines a number of ways to keep your user accounts clean and safe.
Security is hard. It doesn't sit still, and it's difficult to know
how far it needs to extend: if you don't watch yourself, you can end up believing that your boss
needs to understand the beauty of elliptic curves when all he really wants is to make sure the custodian
doesn't read his annual budget.
However challenging it is to keep up with all facets of computing
security, a few areas have matured enough to be worth learning methodically. The first one I recommend
to anyone working with Linux servers is account management.
Tend to your users
Many of the first wave of books devoted to Linux administration and programming included a chapter
on "user management" or "account management." Their meaning was rather specific: how to set up and
maintain the computing accounts and group affiliations for the people who use your host.
At that time, "use" necessarily meant "log in to." Account management was all
about working with commands such as useradd,
chsh, and so on, to configure Linux
accounts that would be convenient for a user population dominated by fellow developers. /etc/passwd
and its APIs were the focus of Linux experts.
Those times are long past, and the first recommendation I make for
most servers is to eliminate most of /etc/passwd. What I mean is this: For historical reasons, most
e-mail servers, Web servers, file servers, and so on, manage their user access in terms of /etc/passwd.
I think this is generally a mistake. It was a sensible practice earlier in our history, when one
or two dozen engineers might share a high-end workstation. Conventional /etc/passwd practices are
a mistake, though, when one e-mail server might handle mailboxes for tens of thousands of users,
for most of whom computing is just another utility like the water fountain or telephone system.
It's certainly possible to rely on /etc/passwd. It's been patched
and tweaked enough to handle surprising workloads. It shouldn't have to, though. If you move user
accounts into a dedicated datastore, such as an LDAP (lightweight directory access protocol) or even
an RDBMS (relational database management system) datastore, you gain advantages in scalability, security,
and maintenance. Restrict /etc/passwd to the few developers and administrators who truly need logins.
This practice gives a big advantage in security, because the duty
cycles of service (e-mail, Web, and so on) users are entirely different from those of developers.
Once you have burned in a new server, its /etc/passwd shouldn't change often. It's an easy job to
monitor it for any updates and, particularly, for tampering. If you're running a large server, though,
you might have several new and expired e-mail account changes daily. You need to isolate those from
the wider access that /etc/passwd gives.
Is construction of an alternate account datastore a serious recommendation?
Yes it is, as surprising as that may seem. A lot of effort has gone in over the years to make very
large /etc/passwds, filled mostly with login-free users, work properly. If you do decide to code
your own account authentication, and you rely on such traditional e-mail programs as
sendmail, you might well find yourself
writing changes for SMTP, POP3, and IMAP4 servers.
Those obstacles generally incline developers toward using off-the-shelf
software. My habit is to favor solutions others have written and that I can re-use. One difference
with these industrial-use servers, though, is that I often need to customize them anyway -- to set
up special message directories, logging information, or usage accounting, for example. What decides
the issue for me is a preference to modularize security considerations. I like to be able to manage
developer and administrator accounts entirely separately from end-user services. By splitting off
the latter from /etc/passwd, I can easily lock down either side without affecting the other.
Almost as important as separating developer accounts from user services is to automate policy.
Establish specific, detailed processes for creating and deleting accounts, both developer (/etc/passwd)
and end-user (e-mail, Web, database, and so on). While it's good discipline to capture these into
executables, it's not strictly necessary. What is important is that the processes be understandable
and unambiguous. Casual account creation and deletion always leaves security holes. Review
your processes with your human resources, customer support, or other pertinent departments. It's
hard to appreciate how crucial this is unless you've lived through the alternative.
When you don't have written procedures for adding and removing users,
the invariable result is that a new worker shows up on Monday, say, and by Friday still can't get
to his or her company files. Or someone resigns, says goodbye at the holiday party, and is still
retrieving occasional corporate assets as February begins.
One of the incidental benefits of account automation is that it encourages
more thorough validation. If developers don't have a convenient way to configure accounts with different
properties, they're quite unlikely to exercise applications that are supposed to differentiate those
configurations.
I recently experienced this first-hand. I was called in on an emergency
in which our implementation team had "correctly," in effect, allowed managers to review employee
performance reviews -- even for employees they didn't manage! As ridiculous as that sounds, it's
typical of security issues. It had even been flagged a couple of times during analysis and design
reviews. Every time it was brought to a decision-maker, though, it was part of a sufficiently large
and muddy collection of problems that it was passed on without crisp resolution.
Only when a support specialist finally set up a concrete example of
a general instance -- one with multiple managers, each of whom had multiple employees reporting in
-- did the error get the attention it deserved. Save yourself last-minute dramas; make configuration
of all sorts of user accounts routine and available for thorough testing.
The hardest part of security, at least for many of us, is to avoid doing dumb things. Security
is one of the "weakest link" affairs, where a single loophole can make all the rest of your investment,
however huge and well-planned, laughably pointless. To do security well, you have to stay on the
alert for things that you aren't otherwise thinking about.
U.S. government sites frequently exemplify the magnitude of that challenge.
One federal agency, frequently in the news for security issues in the "anti-terrorist" sense, maintains
a Web site where user passwords are displayed in the open, on the page for changing user preferences.
Quite a few organizations address the frequency of lost passwords by assigning passwords based
on more-or-less public information (for example, "your password is the first four letters of your
birthplace, followed by the final two digits of your birthyear").
How can you avoid such catastrophic mistakes? Unfortunately, there
are few systematic ways to succeed at such an abstract goal as "being smart." Among the useful steps
to take, though, are study of the RISKS digest and disciplined engineering review.
RISKS is an online newsletter that Peter G. Neumann has been editing
since 1985 (see Resources below). Reading it is excellent practice in thinking
about how things -- security on your Linux servers, in particular -- can go wrong. Neumann makes
the digest quite readable and entertaining, if occasionally macabre.
You should also acquire the habit of trying out your ideas on others.
You might think of "software inspection" as no more than a way to spot misplaced punctuation in developers'
source code, but it's actually a far more interesting and productive practice. In particular, inspections
are a great way to organize peer reviews of requirements documents, Web sites, and all sorts of other
artifacts. Stage inspections. See your work through the eyes of others. You'll probably learn a lot
about the security, or insecurity, of your servers.
The Resources point to more reading on the subjects of hardening servers,
Linux security, and inspections. While server security is an enormous subject, you can pursue the
aspects this column describes quickly and inexpensively. If you haven't looked into these approaches
already, you should; they'll improve the security of your operations a great deal.
What problems of server security are hardest for you? "Server clinic"
will return to the security topic at least a couple more times in the coming year. If you
write to me or
post your thoughts in our forum, I'll try to address your issues.
"Addressing
security issues in Linux" is an IBM whitepaper that discusses various security issues, outlines
strategies for dealing with them, and lists IBM as well as non-IBM products that can help keep
systems buttoned up.
The RISKS
Digest page provides access to subscription information and indexes to back issues of The
RISKS Digest.
LinuxSecurity.com
is a community resource that points to valuable information.
Software Inspectionsis a marvelous book on the subject. The discipline applies
far more broadly than to just the "code reviews" the title brings to many programmers' minds.
The Software Engineering Institute formally defines
software
inspections at its site.
The SANS Institute
is the ideal place to locate resources having to do with system administration, networking, and
security.
The IBM
Security Web site contains an overview of security solutions, hardware/software, products,
research technology, announcements, press releases, and more.
User management is one of the most tedious tasks in a systems administrator's job. There have
been some attempts to centralize user management with NIS and NIS+. NIS fizzled out because of its
security holes, and NIS+ is not very straightforward to configure. So, what's the best way to centralize
user management in an environment? The answer is looking more and more like LDAP.
LDAP (Lightweight Directory Access Protocol) is quickly emerging as the standard in hierarchical
data, such as user and group data. LDAP servers are designed for an "update seldom, access often"
scenario. One of the roadblocks LDAP has faced in gaining popularity as a centralized user management
system is the effort to get client machines to securely authenticate users. In the past, this required
writing custom PAM modules or trying to configure existing ones. However, as major Unix vendors are
realizing the potential of LDAP, they are including clients in the operating system.
These built-in clients also contain the PAM libraries for authentication with an LDAP server.
These client-side applications are included in the Solaris 8 and 9 distributions, as well as AIX
5L. HP-UX has a free software depot called ldapux that can be found at software.hp.com, and Linux
has an RPM called nss_ldap. These clients include built-in libraries, so fears about writing C programs
to authenticate or having holes in your security can be put to rest.
Server Considerations
Several LDAP servers are available on the market. Currently, the two predominant servers are OpenLDAP
and Sun One Directory Server (formerly iPlanet). If Solaris is your OS for the LDAP server, Sun One
Directory Server is the way to go. It is currently bundled with Solaris 9, and version 5.1 is free
up to 200,000 entries (each distinguished name in the server is considered an entry). Sun One Directory
Server is also available on HP-UX, AIX, and Linux. OpenLDAP is free and can be compiled on most flavors
of Unix, but configuration and compilation take a little more effort.
The LDAP community has created an RFC (RFC 2307) to define a schema for Unix to use LDAP as an
NIS provider. The schema defines all the previous maps that were available for NIS, so it is aptly
named the nis.schema. This schema comes loaded in the standard installation of Sun One Directory
Server. If you are using OpenLDAP or another server, be sure the schema is loaded into your server.
As part of the nis.schema, the following services can be centralized with LDAP: password, shadow
password, groups, and netgroups. Other services, such as DNS, are also available with LDAP, but that
is beyond the scope of this article.
The default communications for the LDAP server and clients are clear ASN1 strings. All information
is sent in clear text. This is the major problem with NIS, so be sure you don't make this mistake
with your LDAP implementation. I recommend using the default communication method during the installation
and initial test. Once you have tested the server and the clients, and are comfortable with the configuration,
switch to SSL.
When configuring your clients, you will need to specify a search base. This is the point in the
directory at which the client starts looking for NIS entries. This functionality allows you to separate
Unix user and group accounts from other parts of the directory. For example, you may want to set
up a group with a distinguished name (DN) of "ou=unix nis, dc=mydomain, dc=com". You can segregate
this more if desired, but all Unix accounts would be under this organizational unit; this DN would
be your clients' search base.
Segregating your NIS environment inside the LDAP server will give you two advantages. The first
advantage is speed. When you specify the start DN, your clients will not have to search through the
entire directory to find the accounts, which will help performance. The second benefit is administrative
flexibility. You can give account administrators access to a specific area of the server, instead
of to your entire directory. You can have different search bases for different Unix clients. If you
do this, note that user accounts will need to be replicated in both search bases to have access to
the different clients.
Adding NIS Entries in the LDAP Server
To add a Unix group into LDAP, you will need to create an entry of object class posixGroup. The
attribute gidNumber corresponds to the Unix GID number for the group. Since the local and LDAP groups
are treated the same, it is important to keep all the gidNumbers in LDAP as well as the local GIDs
unique. The Full Name, or cn attribute, is the name of the group. The memberUid attribute correlates
to the users who are part if that group. Each user will be an additional attribute in the group's
entry. In the example below, users jdoe and scarter are part the admins group:
Here are the instructions for adding entries. If you are unsure how to add an entry into an LDAP
server, copy the above entry information into a file on the LDAP host and run the following command:
You can assign users to groups in two ways; the first way is described above. Each posixGroup
entry will have a list of users. The second method is to assign gidNumbers for each group in the
posixAccount entry (described below). These methods can be intermixed but, for consistency, I recommend
choosing one method. When you create a new user, you will use the object class posixAccount and shadowAccount
along with the standard person object classes. The uid attribute is the user login name, and the
uidNumber is the user's Unix uid. The gidNumber attribute lists the groups to which the user belongs.
When you specify the password, there are multiple ways to store the ciphered password. For authentication
on Unix, you must use the crypt method. This is accomplished by using the {CRYPT} tag in front
of the cipher password:
dn: uid=jdoe, ou=unix nis, dc=mydomain, dc=com
givenName: John
sn: Doe
userPassword: {CRYPT}QGxOG7iX3lbLU
loginShell: /usr/bin/ksh
uidNumber: 343
gidNumber: 900
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: posixAccount
objectClass: shadowaccount
uid: jdoe
cn: John Doe
homeDirectory: /export/home/jdoe
Along with specifying the password, you can also set password options such as length, minimum
characters, expiration, etc. All of the attributes in the NIS schema can be found in RFC2307. With
replication and the correct setup, your LDAP environment will be reliable, but there are still some
users you should keep out of LDAP. The most obvious is root; this user should always be kept local.
I suggest keeping application users local, so even if the network goes down, your applications will
still be able to run (assuming they don't need the network).
LDAP supports the use of netgroups, so you can control user access to individual servers. The
object class is called NisNetGroup and uses the same "triple" notation as NIS. Each entry has three
fields: host, user, and domain. If you leave a field blank, it allows complete access. In the entry
below, jdoe is in the appuser netgroup for all servers, all domains. The user scarter is in the appuser
netgroup only on the server mars, and all users are in the appuser netgroup on the server pluto:
The passwd command can be used to change the password in the LDAP server. The only change
is an extra switch -- the -r option. To change the password for user jdoe:
$ passwd -r ldap jdoe
Configuring the Unix Client
Unfortunately, the client setup is different for each version of Unix. There is an effort on the
Apache Directory project to document the steps for configuring each client. As each configuration
is tested, the documentation will be posted on the Directory Project site. I will use Solaris 9 as
an example for the rest of the article.
The Solaris 9 clients will run a daemon called /usr/lib/ldap/ldap_cachemgr, which will handle
all communication between the client and the LDAP servers. The clients use a configuration profile
stored on the servers and periodically update themselves against the profile. This allows you to
make a configuration change once that will be populated out to clients automatically. To do this,
you need to create an organizational unit for the profile to reside in. Add the following OU:
dn: ou=profile, dc=mydomain, dc=com
ObjectClass: top
ObjectClass: OrganizationalUnit
ou: profile
Next, create the profile. This is accomplished by using the ldapclient command built into
the OS. This command will create LDIF output that will be added as an entry into the server. The
following example will create a profile that will configure the clients to use multiple servers (for
replication and failover) and map where in the directory the NIS information will be stored. This
command can be run on any Solaris 9 machine regardless of whether it is a server or a client:
$ /usr/sbin/ldapclient genprofile \
-a defaultSearchBase="ou=unix nis,dc=mydomain,dc=com" \
-a serviceSearchDescriptor="passwd: ou=unix nis,dc=mydomain,dc=com" \
-a serviceSearchDescriptor="group: ou=unix nis,dc=mydomain,dc=com" \
-a serviceSearchDescriptor="shadow: ou=unix nis,dc=mydomain,dc=com" \
-a serviceSearchDescriptor="netgroup: ou=unix nis,dc=mydomain,dc=com" \
-a authenticationMethod=simple \
-a credentialLevel=proxy \
-a "defaultServerList=192.168.0.155 192.168.0.156 192.168.10.100" > profile.ldif
The profile.ldif file will contain the entry information. Normally, you should not have to do
anything to this file, but you can make changes before adding the entry, if necessary. When you are
happy with the profile, add it to the server:
Once the profile entry has been added, set up each of the clients to use it. On the client machine,
run the ldapclient command with the init option. This command will configure the ldap_cachemgr;
it will also copy the /etc/nsswitch.ldap to /etc/nsswitch.conf and start the client in the background:
If the client does not start or you encounter other problems, you can add debug flags to get more
information. Just add option -d 6 to the command for verbose output:
$ /usr/lib/ldap/ldap_cachemgr -d 6
After ldap_cachemgr is up and running, you can test the connection to the server. It will be easier
to test if you have at least one entry for each NIS component you are using. To get a list of entries
the client finds, run the ldaplist command. You should see all the entries in your search
base:
Once you get the client talking to the LDAP server, you can begin configuring the OS for user
authentication. The first step is to add LDAP as a service in the /etc/nsswitch.conf file. The following
nsswitch.conf file will support user authentication, groups, and netgroups in LDAP. If you are not
using netgroups, replace the passwd: compat entry with passwd: files ldap and delete
the passwd_compat entry:
#
# /etc/nsswitch.conf
#
passwd: compat
passwd_compat: ldap
group: files ldap
#
# All other services are unchanged
#
netgroup: ldap
If you are not using netgroups, you don't need to change the /etc/passwd file. If you are using
netgroups, you will need to add the name of the netgroups with access. You will also need to deny
other net users. The following snippet can be inserted at the end of the /etc/passwd file to allow
users in the netgroup appusers to log onto the server:
+@appusers:x:::::
-:x:::::
After the entry is added, run the pwconv command to update the /etc/shadow file.
You will need to add the LDAP PAM library to the /etc/pam.conf in order to authenticate. The library
should already exist in /usr/lib/security; it will be called pam_ldap.so.1:
#
# Authentication management
#
# login service (explicit because of pam_dial_auth)
#
login auth required pam_authtok_get.so.1
login auth required pam_dhkeys.so.1
login auth required pam_dial_auth.so.1
login auth sufficient pam_unix_auth.so.1
login auth required pam_ldap.so.1
#
other auth required pam_authtok_get.so.1
other auth required pam_dhkeys.so.1
other auth sufficient pam_unix_auth.so.1
other auth required pam_ldap.so.1
#
passwd auth sufficient pam_passwd_auth.so.1
passwd auth required pam_ldap.so.1
other account requisite pam_roles.so.1
other account required pam_projects.so.1
other account required pam_unix_account.so.1
#
# Default definition for Session management
# Used when service name is not explicitly mentioned for session
#
other session required pam_unix_session.so.1
#
other password required pam_dhkeys.so.1
other password required pam_authtok_get.so.1
other password required pam_authtok_check.so.1
other password sufficient pam_authtok_store.so.1
other password required pam_ldap.so.1
Conclusion
Besides GUIs supplied by the LDAP server, command-line clients also exist. These LDAP clients
allow you to add, delete, and modify LDAP entries via the command line and LDIF files. This is useful
for scripting or creating custom application to access LDAP. With the built-in clients, secure connections,
and the ability to build GUIs around the server, LDAP has become a viable solution for user management
and authentication. Not only does it make it easier to administer users, but LDAP also allows much
of the work to be moved to a help desk or level 2 systems administrator support.
Jeff Machols is the Manager of the Unix Administration team for a financial institution and
the co-founder of the Apache Directory Project. He can be contacted at: [email protected].
Space Usage
Quotas in Red Hat(ITtoolbox as adapted from RedHat-L discussion group) - I want
to allocate a certain amount of space for each user, but I'm not sure how to go about this. Does
anyone have any tips?
User Authentication
HOWTO(The Linux Documentation Project) - Explains how user and group information is
stored and how users are authenticated on a Linux system (PAM), and how to secure you system's
user authentication.
Automated
Logins Revisited(Linux Gazette) - As more users adopt GNU/Linux for use on their desktop
PCs, machines with only one user are becoming increasingly common. Many new users have little
use for the multi-user logins that Linux supports. A very common request among new desktop users
is to configure their Linux systems to automatically boot up a graphical desktop environment (i.e.
KDE or GNOME), for a single unprivileged user, without prompting for a login ID or password
Writing PAM
Modules, Part One(O'Reilly Network ) - This is part one of a three part article on
writing PAM modules. This part discusses the background information needed to write modules.
Writing PAM
Modules, Part Three(O'Reilly Network ) - Part Three of a three-part series on PAM
modules. This article discusses the four types of PAM modules: account, authentication, password,
and session. An application needs to completely fulfill the requirements for at least one of the
four types.
Writing PAM
Modules, Part Two(O'Reilly Network ) - This is Part Two of a three-part article on
writing PAM modules. Part One discusses the background information needed to write modules, and
Part Three discusses the critical functions the module must supply. This part discusses the support
code a module author will need to use.
Writing PAM-Capable
Applications, Part One(O'Reilly Network ) - The first of a two-part series on writing
PAM-capable applications. Part One provides the background knowledge and some of the supporting
functions necessary for a developer to effectively use the Pluggable Authentication Modules library.
Writing PAM-Capable
Applications, Part Two(O'Reilly Network ) - In this second part of a part two series,
the author covers how to call PAM authentication, account management, session management, and
token-changing functions. She also covers response codes, setting credentials, and supplying a
default configuration for your application.
ACUA (ACUA ) - This is a software
package designed to facilitate the administration of user accounts and the enforcement of access
restrictions on a Linux system.
fancylogin ( Richard Bergmair
) - fancylogin is a powerful login program for Linux. It can handle shadowed password files,
user-time-terminal/network-verification as done with HP-UX login, etc. It adds a lot of capabilities
for logging logins and support for themes to control the login's look.
gUserMan (Scott Fritzinger
) - gUserMan is user and group management software. Written with GTK+, it allows you to view
existing users and groups sorted by any field, as well as add/edit/remove users and groups with
a few clicks of the button.
Linux-PAM (Andrew
Morgan ) - Linux-PAM provides a flexible mechanism for authenticating users.
QuickSwitch (Edge Solutions) -
QuickSwitch is a utility that lets you switch network profiles on the fly (IP address, DNS, routes
etc.). Very handy if you have a linux laptop and take it all over the place. Future releases will
let you change NFS/NIS and samba defaults on the fly.
Webmin (Webmin) - This is a web-based
interface for system administration for Unix. Using any browser that supports tables and forms
(and Java for the File Manager module), you can setup user accounts, Apache, DNS, file sharing
and so on.
The Last but not LeastTechnology is dominated by
two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt.
Ph.D
FAIR USE NOTICEThis site contains
copyrighted material the use of which has not always been specifically
authorized by the copyright owner. We are making such material available
to advance understanding of computer science, IT technology, economic, scientific, and social
issues. We believe this constitutes a 'fair use' of any such
copyrighted material as provided by section 107 of the US Copyright Law according to which
such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free)
site written by people for whom English is not a native language. Grammar and spelling errors should
be expected. The site contain some broken links as it develops like a living tree...
You can use PayPal to to buy a cup of coffee for authors
of this site
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or
referenced source) and are
not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society.We do not warrant the correctness
of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be
tracked by Google please disable Javascript for this site. This site is perfectly usable without
Javascript.
