SSO is an umbrella term for any time a user can login to multiple applications while only authenticating once. It covers both federation and password vaulting which is more commonly known as “Enterprise SSO”. The main difference is that federation eliminates the requirement to use and remember passwords and Enterprise SSO doesn’t.
Federation allows single sign-on (SSO) without passwords – the federation server knows the username for a Person in each application and presents that application with a token that says, " this Person is domain\johndoe or firstname.lastname@example.org". No password is required for the user to login to each system. Because of the trust between the two systems, the target application accepts this token and authenticates the user. The federation server passes that token using one of the standard identity protocols: SAML, OpenID, WS-Trust, WS-Federation and OAuth. The benefit to federation is security and authentication into both on premise and cloud applications.
Enterprise SSO is when the applications all still require that a password be sent to login, but the software handles storing it and automatically retrieving it for the user and inputting it into the application for an automatic login. The user still has a password for each system that must be provided to login, must be changed on a regular basis, etc.
I like analogies; in my mind, Identity federation is like an amusement park. With Enterprise SSO (ESSO), you get into the amusement park but still need a ticket for each ride (think Santa Cruz Beach Boardwalk). With federation, you get into the amusement park but have a wristband that every ride operator recognizes and lets you on (think Disneyland).
The simplest way to discover someone’s password is to have them tell you it. This can be done by persuading them to type it into a website you control (commonly known as phishing), by installing a keylogger (either hardware or software) on a computer, or by reading traffic on an unencrypted wireless or wired network. For intruders these methods have the great benefit that it does not matter how long or complex a password the user has chosen: the intruder can simply read it. Cracking of hashes/brute force If the intruder cannot obtain the password then he can simply use a program to generate billions of possible passwords (often using the same techniques as are suggested for choosing passwords) and try each of them against the account. The crudest way to do this is to simply attempt to log in using each generated password: the resulting flood of password failures should be easy for a system administrator to spot, but since attackers continue to use this approach it seems it is still reasonably successful. Attempts may be made against obscure authenticated services, such as SSH and LDAP, to reduce the chances of detection.
Brute force attacks are much less obvious if the intruder can obtain a copy of an encrypted password, for example if a system’s password file can be downloaded, if a hash has been included in a public file, or if an unknown machine can join an authentication group. Once the intruder has one or more encrypted passwords he can do the brute force guessing on his own machine (using modern hardware and algorithms this may take only a few minutes for short passwords), or even use a cloud service, and then return to login to the target once the correct password has been discovered.
Password recovery/reset systems
An intruder may not need to get the password from the user if he can persuade the authentication system to either mail it to him or change it to something of his choice. Systems to allow the legitimate user to recover or change a password they have forgotten can also let other people do the same. Helpdesk operators need to be particularly careful to check the identity of anyone asking for a password reset. On-line systems that rely on “secret questions” such as “name of first school” or “birthday” are trivial to defeat if that information can be found on a social network. Systems that send reminders to a backup e-mail address or phone number can fail if the user changes address or number allowing the abandoned backup to be registered by someone else. Educated guesswork It should be obvious that the same techniques used to guess the answers to secret questions can also be used to guess passwords. Anything based on something your friends will know, or that is available from a website, is a very poor choice as a password.
Reuse of Passwords
Most people now have many different accounts on different systems in both their private and work lives. Although best practice is to have a different password for every account, unfortunately it’s much more common to reuse the same password on different services. That means that an organisation doesn’t just have to worry about the above attacks against its own systems, it has to worry about the same attacks on all other systems where the same password has been used. This probably means that an organisation can no longer completely control whether its passwords are secure: it should also develop plans and systems to detect and respond when a password has been compromised.
Equipment and software often has standard pre-configured passwords which, of course, are well known to intruders. Such passwords should always be changed, though it can still be hard to find out where they may have been used. A related problem is where a password is set for the user by a local administrator. Unless the user is required to change the password to one that the administrator does not know, doubt can always be raised which of the two people who knew the password was actually logged in and responsible for the account’s activity. If there are reasons that users cannot be forced to change their passwords on first use then procedures need to be carefully designed and followed to ensure that suspicion does not fall on the wrong person.
Password embedded in code
Passwords are also sometimes disclosed by being included in scripts or programs. While this may appear an easy way to automate access to an interactive system it carries high risks of disclosure and alternatives should be used wherever possible. If there is no other alternative then the script or program must be very carefully protected against deliberate or accidental access. The worst possible outcome is for a script containing a plaintext password to end up on a public website.
In it’s simplest form a Viral Loop is term used for growing your product via referrals.
For example, person uses product -> tells friend -> the friend uses the product -> tells another friend who uses the product -> cycle is repeated.
Defining the viral loop served the purpose of showing how a product might grow sustainably and allow teams to visualise how they might begin to implement a viral element into their product.
Viral loops can happen organically but most of the time companies choose to instigate viral growth by altering the product in some way.
A couple of good examples would be…
There are other viral elements which determine the effectiveness of your Viral-Loop such as the Viral Coefficient & Cycle time.
Viral Coefficient: A measure of Virality
Cycle Time: The average time it takes to complete a viral-loop.