Softpanorama

May the source be with you, but remember the KISS principle ;-)
Home Switchboard Unix Administration Red Hat TCP/IP Networks Neoliberalism Toxic Managers
(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and  bastardization of classic Unix

Authentication and Accounts Security in "After Snowden" world

home > Authentication
News Potemkin Villages of Computer Security Recommended Links

passwd command

chpasswd Password Policy in 'After Snowden" World  eMail Security
PAM Sudo SSH Private and Public key management Password crackers ssh-keygen Writing Passwords Down
Notes on Passwords Policy Root account controls Wheel Group Kerberos Password synchronization Solaris LDAP Shadow Passwords
RBAC Solaris 10 Role Based Access Control (RBAC) Smart Cards SecurID Tokens Notes on Passwords Policy SecurID on Suse SecurID Token Activation
Application password security PAM (Pluggable authentication modules) Authentication token manipulation error Stanford compromise History Humor Etc

Introduction

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:

  1. 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.
     
  2. 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.
     
  3. 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.

Complexity of passwords is mostly bogeyman -- it does not matter much, the real issues are password length, and the usage of two factor authentications

You need to avoid "truthful" answers on security questions: it is better to construct some virtual personality, for example using data from your deceased relative instead

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)

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:

  1. Assume that there is hunting season for large commercial sites accounts from various intelligence agencies and hackers.
  2. 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. 
  3. 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
  4. 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.
  5. Increasing waiting period after each failed login attempt or series of attempts.  This is a must in "After Snowden" world.
  6. 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.
  7. 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. 

Shadow file stores hashes not actual passwords

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/shadow file. But stealing it means that you should be root on the particular server. So there is a Catch 22 situation.

Cracking passwords makes sense if and only if users reuse passwords on different servers

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:

The common blunder of usage the same password on several servers/sites

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

Tips for ensuring better password security

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):

  1. 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.
  2. 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. 
     
  3. 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.
  4. 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.
     
  5. 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)
  6. 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.
  7. 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.
  8. 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
  9. 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
  10. 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.
  11. Use wheel group and corresponding PAM module for users who are allowed to switch to root.
  12. 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.
  13. 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.
  14. Standardize and write-protect the "root" account's startup files. Minimize the number of users with "super user" privileges
     
  15. Minimize the number of accounts on security sensitive servers and "critical" hosts
  16. 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.

Lesson of Podesta and yahoo case: never use single factor authentication with web email

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

  1. You'll enter your password. Whenever you sign in to Google, you'll enter your password as usual.
  2. 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:

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.


Top Visited
Switchboard
Latest
Past week
Past month

NEWS CONTENTS

Old News ;-)

[Aug 03, 2021] some of us are, in the year of our lord 2021, still reusing the same password for multiple sites by Gareth Corfield You just save it in Chrome or Firefox? Ugh. And then it autofills when you need it again? Oh the horror

Jul 30, 2021 | www.theregister.com

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. ®

[Mar 01, 2021] Monitoring failed login attempts on Linux - Network World

Mar 01, 2021 | www.networkworld.com

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.

me title=

A password login screen overlaid against an abstract background of data and network connections.
Vladimir Kazakov / Getty Images

me title=

https://0676ec3f89d218285b52076f429c0b0c.safeframe.googlesyndication.com/safeframe/1-0-37/html/container.html

https://0676ec3f89d218285b52076f429c0b0c.safeframe.googlesyndication.com/safeframe/1-0-37/html/container.html

https://0676ec3f89d218285b52076f429c0b0c.safeframe.googlesyndication.com/safeframe/1-0-37/html/container.html

https://0676ec3f89d218285b52076f429c0b0c.safeframe.googlesyndication.com/safeframe/1-0-37/html/container.html

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:

[Get regularly scheduled insights by signing up for Network World newsletters.]
$ sudo grep "Failed password" /var/log/auth.log | grep -v COMMAND | awk '{print $9}' | sort | uniq -c
     22 nemo
      1 shs
      2 times:

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.

https://imasdk.googleapis.com/js/core/bridge3.444.1_en.html#goog_2129280102

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:

$ sudo grep "Failed password" /var/log/auth.log | grep -v COMMAND | awk '{print $11}' | sort | uniq -c
     23 192.168.0.7

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:

$ sudo grep "Failed password" /var/log/secure | awk '{print $9}' | sort | uniq -c
      6 nemo

Check settings in the /etc/pam.d/password-auth and /etc/pam.d/system-auth files. Adding lines like these will enforce your settings.

Adobe Experience Platform Enhancements to Help Retailers Meet the Challenges of 2021

SponsoredPost Sponsored by Adobe

Adobe Experience Platform Enhancements to Help Retailers Meet the Challenges of 2021

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:

$ ls -l /var/log/faillog
-rw-r--r-- 1 root root 32576 Nov 12 12:12 /var/log/faillog
$ od -bc /var/log/faillog
0000000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
         \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
0077500

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.

Feeding the World through Science

SponsoredPost Sponsored by Dell Technologies and Intel®

Feeding the World through Science

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).

auth  required   pam_tally2.so deny=6 unlock_time=300
Wrap-Up

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.

[Aug 01, 2020] Anatomy of a Linux Pluggable Authentication Modules (PAM) configuration file - Enable Sysadmin

Aug 01, 2020 | www.redhat.com

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.

$ rpm -qf /etc/pam.d/sudo
sudo-1.9.0-0.1.b4.fc31.x86_64

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.

$ cat /etc/pam.d/system-auth
...omitted...
session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

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.

[Jul 24, 2020] An introduction to Pluggable Authentication Modules (PAM) in Linux - Enable Sysadmin by Susan Lauber

Jul 22, 2020 | www.redhat.com

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.

More Linux resources

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:

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.

[Oct 22, 2019] Computer Historians Crack Passwords of Unix's Early Pioneers

Oct 22, 2019 | tech.slashdot.org

(boingboing.net) 60

Posted by BeauHD on Thursday October 10, 2019 @05:00PM from the cracking-the-code dept. JustAnotherOldGuy shares a report from Boing Boing:

Early versions of the free/open Unix variant BSD came with password files that included hashed passwords for such Unix luminaries as Dennis Ritchie, Stephen R. Bourne, Eric Schmidt, Brian W. Kernighan and Stuart Feldman. Leah Neukirchen recovered an BSD version 3 source tree and revealed that she was able to crack many of the weak passwords used by the equally weak hashing algorithm from those bygone days .

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.

Re:Only paranoid people need secure passwords ( Score: 4 , Interesting) by lgw ( 121541 ) on Thursday October 10, 2019 @05:39PM ( #59293980 ) Journal

Kernighan's password was rather good. It's a sad state of affairs that it would be blocked by so many websites today.

Re:Only paranoid people need secure passwords ( Score: 5 , Informative) by yorgasor ( 109984 ) < ron.tritechs@net > on Thursday October 10, 2019 @10:16PM ( #59294702 ) Homepage

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.

Re:password ( Score: 5 , Funny) by vittico ( 1086555 ) on Thursday October 10, 2019 @06:32PM ( #59294150 )

well... Bourne used bourne just saying...

e:password ( Score: 5 , Funny) by 93 Escort Wagon ( 326346 ) on Thursday October 10, 2019 @07:51PM ( #59294374 )

To be fair, he wasn't using his name - he was using the name of his preferred shell.

done back in the 1980's, probably ( Score: 5 , Informative) by david_bonn ( 259998 ) < davidbonn@m[ ]com ['ac.' in gap] > on Thursday October 10, 2019 @05:31PM ( #59293954 ) Homepage Journal

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.

Different world back then ( Score: 5 , Informative) by Mike Van Pelt ( 32582 ) on Thursday October 10, 2019 @06:35PM ( #59294170 )

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.

After 50 years ... ( Score: 2 ) by Retired ICS ( 6159680 ) on Friday October 11, 2019 @05:06AM ( #59295306 )

So after 50 years they managed to crack a password. News at 11. Seems to me that the original algorithm was pretty damn secure!

Re:After 50 years ... ( Score: 1 ) by ebvwfbw ( 864834 ) on Friday October 11, 2019 @01:55PM ( #59296772 )

Not really. Some of us cracked those passwords more than 20 years ago when John came out.

Good enough in the day ( Score: 2 ) by Shirley Marquez ( 1753714 ) on Friday October 11, 2019 @03:07PM ( #59297084 ) Homepage

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.

[Aug 18, 2019] Hundreds of Thousands of People Are Using Passwords That Have Already Been Hacked, Google Says

Aug 18, 2019 | tech.slashdot.org

(vice.com) 58

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.

[Mar 29, 2018] Answers to questions to recover password should never be truthful

Notable quotes:
"... So long as you choose from fictional sources which mean something to you, it's pretty easy to remember those answers. ..."
Mar 29, 2018 | discussion.theguardian.com

AlanAudio -> SamXTherapy , 28 Mar 2018 10:24

It's easy to use simple to remember associations from fiction.

For instance, your first school could be Grange Hill, Greyfriars or St Trinians.

First car could be Genevieve, Chitty Chitty Bang Bang, or maybe James Bond's Aston Martin.

Mother's maiden name could be a favorite author while your first pet's name could be Lassie, Trigger or Peter Rabbit.

So long as you choose from fictional sources which mean something to you, it's pretty easy to remember those answers.

[Oct 25, 2017] How to Lock User Accounts After Failed Login Attempts

Oct 25, 2017 | www.tecmint.com

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.

auth    required       pam_faillock.so preauth silent audit deny=3 unlock_time=600
auth    [default=die]  pam_faillock.so authfail audit deny=3 unlock_time=600

Where:

Note that the order of these lines is very important, wrong configurations can cause all user accounts to be locked.

The auth section in both files should have the content below arranged in this order:

auth        required      pam_env.so
auth        required      pam_faillock.so preauth silent audit deny=3 unlock_time=300
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_success
auth        required      pam_deny.so

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.

account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     required      pam_permit.so
account     required      pam_faillock.so
How to Lock Root Account After Failed Login Attempts

To lock the root account after failed authentication attempts, add the even_deny_root option to the lines in both files in the auth section like this.

auth        required      pam_faillock.so preauth silent audit deny=3 even_deny_root unlock_time=300
auth        [default=die]  pam_faillock.so  authfail  audit  deny=3 even_deny_root unlock_time=300

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.

# systemctl restart sshd  [On SystemD]
# service sshd restart    [On SysVInit]
How to Test SSH User Failed Login Attempts

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

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

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

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

auth  required      pam_env.so
auth   [success=1 default=ignore] pam_succeed_if.so user in tecmint:aaronkilik 
auth   required      pam_faillock.so preauth silent audit deny=3 unlock_time=600
auth   sufficient    pam_unix.so  nullok  try_first_pass
auth   [default=die]  pam_faillock.so  authfail  audit  deny=3  unlock_time=600
auth   requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth   required      pam_deny.so

For more information, see the pam_faillock and faillock man pages.

# man pam_faillock
# man faillock

[Sep 25, 2017] Artificial Intelligence Just Made Guessing Your Password a Whole Lot Easier by Matthew Hutson

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.
Sep 15, 2017 | www.sciencemag.org

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."

[Dec 26, 2016] A Typo Led To Podestas Email Hack, Says Report

Dec 26, 2016 | yro.slashdot.org
(thehill.com) 274

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.

[Dec 26, 2016] U2F Security Keys May Be the World's Best Hope Against Account Takeovers

Notable quotes:
"... 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. ..."
Dec 26, 2016 | it.slashdot.org
(arstechnica.com) 153

Posted by BeauHD on Friday December 23, 2016 @09:05PM from the new-kid-on-the-block dept.

earlytime writes:

Large scale account hacks such as the billion user Yahoo breach and targeted phishing hacks of gmail accounts during the U.S. election have made 2016 an infamous year for web security. Along comes U2F/web-security keys to address these issues at a critical time.

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."

The researchers wrote in a recently published report :

"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."

[Nov 06, 2016] The Podesta Emails - Undeniable proof that the lobbyists wanted to put Bernie out

Notable quotes:
"... 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. " ..."
Nov 06, 2016 | failedevolution.blogspot.gr
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.

An email from Gary Hirshberg, chairman and former president and CEO of Stonyfield Farm , to John Podesta on March 13, 2016, confirms why the lobbyists strongly opposed Bernie Sanders.

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. "

[Nov 04, 2016] the Podesta emails show compete corruption of democratic party

Notable quotes:
"... 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. ..."
Nov 04, 2016 | www.theguardian.com

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.

[Nov 03, 2016] John Podesta and Mook conspiring to commit money laundering

Nov 03, 2016 | www.nakedcapitalism.com

oho November 3, 2016 at 3:03 pm

John Podesta + Mook conspiring to commit money laundering. Not hyperbole.

https://mobile.twitter.com/wikileaks/status/794236216681992192/photo/1

Portia November 3, 2016 at 3:06 pm

3k/mo ok for you?

why yes

[Nov 03, 2016] Off The Record dinner at Podestas with reporters covering Clinton

Notable quotes:
"... Hillary wouldn't even be close if the press weren't in the tank for her ..."
Nov 03, 2016 | www.zerohedge.com

JackMeOff Nov 3, 2016 9:37 AM

Off The Record dinner at Podesta's with reporters covering Clinton:

https://wikileaks.org/podesta-emails/emailid/43604

The goals of the dinner include:

(1) Getting to know the reporters most closely c overing HRC and getting them comfortable with team HRC

(2) Setting expectations for the announcement and launch period

(3) Framing the HRC message and framing the race

(4) Demystifying key players on HRC's campaign team

(5) Having fun and enjoying good cooking

I am a Man I am... JackMeOff Nov 3, 2016 10:01 AM ,
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?

[Oct 30, 2016] Speaking also of Pedesta email it is interesting that it was Podesta who make mistake of assessing phishing email link, probably accidentally

turcopolier.typepad.com

mistah charley, ph.d. said... 30 October 2016 at 09:13 AM

Speaking also of Podesta's email, not Huma's, the following is interesting:

http://www.cnn.com/2016/10/28/politics/phishing-email-hack-john-podesta-hillary-clinton-wikileaks/index.html

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."

[Oct 29, 2016] Sometimes Bill And Hillary Have The Worst Judgment Wikileaks Releases Part 22 Of Podesta File

Notable quotes:
"... and concludes by saying that " Sometimes HRC/WJC have the worst judgement ." In retrospect, she is right. ..."
Oct 29, 2016 | www.zerohedge.com
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.

RELEASE: The Podesta Emails Part 22 #PodestaEmails #PodestaEmails22 #HillaryClinton https://t.co/wzxeh70oUm pic.twitter.com/QnWewcpPbf

- WikiLeaks (@wikileaks) October 29, 2016

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

* * *

A February 2015 email from Neera Tanden lashes out at David Brock of the Bonner Group, profiled in this post: " Money Laundering Scheme Exposed: 14 Pro-Clinton Super PACs & Non-Profits Implicated ." As a reminder, the Bonner Group, as we showed last month, may be a money laundering front involving various SuperPACs and non-profit institutions:

In the email Tanden says that:

"Brock/Bonner are a nightmare: Really, Suzie Buell isn't giving to the superpac? I wonder how that got in this story " Big donors holding off making pledges to pro-Hillary Clinton super PAC ",

and concludes by saying that " Sometimes HRC/WJC have the worst judgement ." In retrospect, she is right.

* * *

Speaking of "donor advisor" Mary Pat Bonner , the following email from March 2009 hints at potential impropriety in shifting money from one democratic donor group to another, the Center for American Progress :

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.

The email :

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.

[Oct 26, 2016] Over-sampling issue in Podesta emails

Notable quotes:
"... 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. ..."
crookedtimber.org

kidneystones 10.25.16 at 11:07 am ( 55 )

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.

[Oct 19, 2016] Wikileaks Releases Another 1803 Podesta Emails In Part 12 Of Data Dump; Total Is Now 18953

Notable quotes:
"... 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. ..."
Oct 19, 2016 | www.zerohedge.com
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.

RELEASE: The Podesta Emails Part 12 https://t.co/wzxeh70oUm #HillaryClinton #imWithHer #PodestaEmails #PodestaEmails12 pic.twitter.com/druf7WQXD5

- WikiLeaks (@wikileaks) October 19, 2016

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...

* * *

We find more evidence of media coordination with Politico's Glenn Thrush who has an off the record question to make sure he is not "fucking anything up":

From: [email protected]
To: [email protected]
Date: 2015-04-30 17:06
Subject: Re: sorry to bother...

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.

CuttingEdge X_in_Sweden Oct 19, 2016 9:18 AM

Is Podesta authorised to be privy to confidential information?

Only Hillary sends him a 9-point assessment of the ME with this at the top:

Note: Sources include Western intelligence, US intelligence and sources in the region.

I would assume Intelligence Services intel based assessments would be a bit confidential, Mr Comey? Given their source? Nothing to see here, you say?

Fuck Me.

https://www.wikileaks.org/podesta-emails/emailid/18917

Bubba Rum Das samjam7 Oct 19, 2016 9:02 AM

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)!

Oh, yeah...-And THANK YOU, MR. O'KEEFE!

css1971 Oct 19, 2016 9:04 AM

Dems!! Dems!! Where are you. You need 2 more bimbos to accuse Trump of looking at them!!

DEMS you need to get that nose to the grindstone!!

Hobbleknee GunnerySgtHartman Oct 19, 2016 8:48 AM

Fox is controlled opposition. They dropped the interview with O'Keefe after he released the latest undercover report on Democrat voter fraud.

JackMeOff Oct 19, 2016 10:16 AM

Wonder what "docs" they are referring?

https://wikileaks.org/podesta-emails/emailid/17978

monad Oct 19, 2016 1:14 PM The FBI had no difficulty convicting Obugger's crony Rod Blagegovitch.

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.

california chrome Oct 19, 2016 11:03 AM

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.

http://graphics.latimes.com/usc-presidential-poll-dashboard/

whatamaroon Oct 19, 2016 1:04 PM https://pageshot.net/qLjtSLje2gBJ1Mlp/twitter.com ,

This supposedly directly implicates Podesta and voter fraud. If it will open here

[Jun 10, 2016] Progress did not touch humans for the last 50 years in such an area as creating passwords

Stupidity is still rampant.

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!

[Nov 08, 2015] Single command shell accounts

Notable quotes:
"... /etc/ssh/sshd_config ..."
"... /home/restricteduser/.ssh/authorized_keys ..."
nickgeoghegan.net

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

[Nov 05, 2015] Six Tricks for Using Your Biography to Make Strong Passwords By Brady Dale

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.
Oct 25, 2015 | observer.com

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):

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.

See also:

[Dec 24, 2014] JPMorgan Chase hack due to missing 2-factor authentication on one server

Dec 23, 2014 | Ars Technica

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, The New 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.

[Jul 16, 2014] Microsoft tells internet users that they are 'better off' reusing old passwords than creating new ones by Chris Green

Complex, unique passwords should only be used to access highly sensitive data such as a person's bank account
July 16, 2014 | independent.co.uk

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.

[Apr 19, 2013] Microsoft moves to optional two-factor authentication By Joab Jackson

They are ten years late, but better late then never. The chief form of secondary authentication will be a short code sent to the user's mobile phone
April 17, 2013 | ITworld

... ... ...

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.

[Oct 31, 2011] When passwords attack the problem with aggressive password policies

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.

[Aug 10, 2011] Password Myths

August 10, 2011 | Cuddletech

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:

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.

[Mar 22, 2007] Windows Security and Directory Services for UNIX Guide v1.0

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.

[Mar 22, 2007] Active Directory Integration HP-UX 11

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.

Jason Zions
Microsoft Corporation

Disclaimer: All information is provided as-is.

[Mar 22, 2007] SUMMARY Solaris login based on Windows Domain

John Christian john.christian at TheCReGroup.com
Wed Sep 15 16:57:00 EDT 2004
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...]

[Mar 22, 2007] Slashdot pam_ldap-pam_krb5 Authentication Against Active Directory

[Mar 21, 2007] blog.scottlowe.org " Blog Archive " Solaris 10 and Active Directory Integration

As with the procedure for authenticating Linux against Active Directory and providing Kerberos-based SSO with Apache, there are a few steps to be performed. Some of these steps are performed on the Active Directory side, some of them are performed on the Solaris 10 system.

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...

{PPT} Windows and Unix Account Management and Authentication Integration

File Format: Microsoft Powerpoint 97 - View as HTML Kerberos Authentication. Active Directory. SFU NIS Extensions. LDAP Queries ... SFU NIS Extensions.

[Jan 24, 2005] Hackers eavesdrop on phone networks to steal data

Computerworld

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.

Server clinic Practical Linux security

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.

Automate policy

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.

Stay alert

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.

Conclusion

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.

Resources

NCSA HPC Account Management

  1. Managing your Account
    1. Passwords
    2. Your shell
    3. Managing your "dot" files
    4. Forwarding your mail
  2. Managing your Allocation
    1. Adding/removing users
    2. Charging Algorithms
    3. Verifying Your Account Balance
    4. Changing Projects for Charging
    5. Refunds
    6. Account Termination, Renewals, and Extensions

Sys Admin Magazine Using LDAP to Manage Unix Accounts Jeff Machols

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:

dn: cn=admins, ou=unix nis, dc=mydomain, dc=com
gidNumber: 900
memberUid: jdoe
memberUid: scarter
objectClass: top
objectClass: posixgroup
cn: admins

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:

$ ldapadd -D "directory_manager_dn" -w "directory_manager_password" -f filename

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:

dn: cn=appuser, ou=unix nis, dc=mydomain, dc=com
        nisNetgroupTriple: ( , jdoe , )
        nisNetgroupTriple: ( mars , scarter , )
        nisNetgroupTriple: ( pluto , , )
        cn: appuser
        objectClass: top
        objectClass: nisnetgroup

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:

$ ldapadd -D "directory_manager_dn" -w "directory_manager_password" \
  -f profile.ldif

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:

$ ldapclient -v init -a proxyDN=" directory_manager_dn" \
  -w "directory_manager_password" ldapserver_IP_address

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:

$ ldaplist

dn: cn=admins, ou=unix nis, dc=mydomain,dc=com
dn: uid=jdoe,ou=unix nis,dc=mydomain,dc=com
dn: cn=appuser, ou=unix nis, dc=mydomain,dc=com

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].


Recommended Links

Google matched content

Softpanorama Recommended

Top articles

Sites

PAM Essentials


Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotesSomerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose BierceBernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOSProgramming Languages History : PL/1 : Simula 67 : C : History of GCC developmentScripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology 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


Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

FAIR USE NOTICE This 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.

Last modified: August 02, 2020