|
|
| Line 1: |
Line 1: |
| {{SecurityRelated}}
| | (temporarily elsewhere) |
| | |
| ==Identity, authentication, and authorization==
| |
| | |
| <!--
| |
| There is the concept of a security '''Actor'''/'''principal'''/whatnot, that is, the thing/person that wants to act, and as such has to deal with the security system.
| |
| | |
| '''Identity''': A claim by an actor.
| |
| : An answer to "Who are you?"
| |
| : often a person, or computer
| |
| : Generally a public thing, in that people can see the identity
| |
| :: and in some systems that has added value, in that you can say something about specific identities.
| |
| : Identities should be unique
| |
| | |
| A declaration of who you are, usually a person or a computer.
| |
| | |
| Includes user IDs, certificates (public key cryptography), plastic cards, etc.
| |
| | |
| The assertion of your identity, and often the identity itself, are effectively public things (at least between the systems in use).
| |
| | |
| | |
| | |
| '''Authentication''': Proof of the claim of an identity.
| |
| : An answer to "is this actor really who they claim they are? / how can you prove it?".
| |
| : Often verifies a shared secret, such as a password.
| |
| | |
| | |
| "How can you prove it?"
| |
| | |
| Some way of supporting your claim of a certain identity.
| |
| | |
| | |
| Usually a challenge, response, and verification.
| |
| | |
| Often based somehow on knowing a secret,
| |
| so authentication is a private thing.
| |
| | |
| | |
| Includes passwords and PINs, public key cryptography exchanges, and such.
| |
| | |
| Often something you know or have, with optional consideration of how revealing the process of authentication is, if mischievously observed.
| |
| | |
| | |
| The means of proving identity tends to be private (unlike the identity you are trying to prove).
| |
| | |
| Note that biometrics blur the lines between identity and authentication.
| |
| Various biometrics aren't exactly private, which means the proof isn't very private either.
| |
| This ends up shifting risks to users.
| |
| | |
| | |
| | |
| | |
| '''Authorization'': Resource control.
| |
| : answers "is this authenticated identity A allowed to do action B?".
| |
| | |
| | |
| Identity and authentication are usually separated.
| |
| Identity is public, authentication is not.
| |
| | |
| Identities should be unique, authenticators (e.g. passwords) need not be (shouldn't be forced to be, as that could indirectly reveal information, in the case of passwords that one of the other users has exactly that password).
| |
| | |
| | |
| Ideally speaking, authentication checks identity, but this is actually very hard - in general.
| |
| (Even our international go-to, passports, are only so good).
| |
| | |
| In computer security, what you actually check is "is this login valid",
| |
| With passwords it checks only something you ''know''.
| |
| | |
| Since this can be shared easily, it doesn't necessarily check identity.
| |
| | |
| | |
| | |
| Usually this is not very fine-grained because the (time) cost of the bother to administer is counterproductive to productivity (...which can cause people to subvert the system to get ''anything'' done, in which case it's counterproductive to security).
| |
| | |
| | |
| | |
| | |
| ----
| |
| | |
| | |
| | |
| Biometrics tries identity and authentication - it's something you ''have'', although this this is also relatively public to start with - fingerprint, voice, eye.
| |
| | |
| Most such aspects are also too fuzzy to be useful identification ''in itself'',
| |
| due to their false positive/negative rate.
| |
| Combinations work better.
| |
| | |
| | |
| Smart cards are 2-factor auth base authentication on something you physically (which is public enough, in that it can get stolen without your knowledge) have, ''and'' on a secret.
| |
| | |
| | |
| The separation of identity and authentication is mostly handy in that it makes theft less serious.
| |
| If your password gets stolen (and if you can tell) you can change the password and don't necessarily have to create a new identity.
| |
| If your smart card is stolen, you may not be able to log in, but without the PIN the thief can't either (depending a little on design), and it's also a lot simpler to know that it has been stolen, and to report it.
| |
| | |
| | |
| A number of details above also deal with minimizing indirect information malicious people can derive from the system, but there are a lot of minor details to a login system that you also need to get right for this.
| |
| | |
| Centralization can be useful and not.
| |
| | |
| | |
| | |
| | |
| | |
| Note that some systems only authenticate. Login systems on the web usually have a single login and a cookie that signifies 'has logged in'. Even if they secure password changing and such, this is often done by just asking for the password again. An authorization system is often not necessary for these cases.
| |
| | |
| Isolated authorization can also be useful. For example, in picasa
| |
| web albums, unlisted albums can be shared without having to use
| |
| user management by copying the URL including an authkey. That authkey
| |
| is nothing more than a token that lets anyone that has it access
| |
| the identified album, and the authkey can be revoked (changed and
| |
| shared again) if you wish.
| |
| | |
| Only identification also happens, and can be enough in cases where all users trust each other and only have the preference of having things associated with themselves. For example, a set of passwordless accounts in windows to each have their own media library but with minimal bother.
| |
| | |
| | |
| -->
| |
| | |
| | |
| | |
| | |
| | |
| | |
| <!--
| |
| ==On password choice==
| |
| | |
| The primary things to worry about are
| |
| * '''online brute force''' - a remote system trying to log in repeatedly.
| |
| : Server-side: Simple attempts can be alleviated with backoff per IP. Distributed attempts are harder to block because it's hard to tell apart the real user.
| |
| : User side: Use decent passwords, and don't reuse them (This will generally only help an attacker if you either have a very typical password, or they have one from another breakin and you are reusing it)
| |
| | |
| * '''offline brute force''' - if a system gets hacked, the file with password hashes is a common thing to steal. You can run crackers against such files that run so much faster than online brute force that they can try ''all'' passwords up to a particular length within reasonable time
| |
| ** '''short passwords are bad''' mainly because these tend to run long enough to try passwords up to a some length (and give up after a while because there is exponentially more to try for each extra character)
| |
| :: this is the main reason behind "minimum 8 characters" and such.
| |
| | |
| | |
| * '''avoid using very few passwords for a lot of sites''' - for example one password for serious sites, one for the rest
| |
| : Reason: on a successful login, it's trivial to check the same username-password combination elsewhere. For you: If one account gets hacked, you suddenly have to scramble to find out what others you used it on.
| |
| : Alleviation: Use a simple ruleset for passwords. Something cleverer is better, but even something predictable like "base password plus first letters from the service name" is decent, because most hacking targets systems, not specific people. They usually don't have the time or interest to look at you specifically.
| |
| | |
| | |
| * '''predictable is bad in general''' - fairly random attempts with common usernames and common passwords like 12345 and 1q2w3e works more than you would think.
| |
| | |
| | |
| -->
| |
| | |
| ==Auth systems - setup considerations==
| |
| | |
| | |
| ===Local authentication===
| |
| | |
| ===Centralized authentication===
| |
| | |
| ===Shared authentication===
| |
| <!--
| |
| When a bunch of systems are related, by proximity and shared ownership (e.g. all those within a company) or whatever else, if can make sense to have them share the same means of authentication on each, rather than a separate account on each system.
| |
| | |
| | |
| This can be done in various ways
| |
| * allow the same sort of login on each
| |
| : e.g. synchronizing password hashes on various workstations
| |
| | |
| * trusting login on one on the other
| |
| : also
| |
| | |
| * delegating auth to a central server
| |
| : e.g. central LDAP
| |
| | |
| * single sign-on
| |
| : token system
| |
| | |
| -->
| |
| | |
| ===Tokens and tickets===
| |
| <!--
| |
| | |
| | |
| '''Mechanically'''
| |
| | |
| Tokens are often used to allow something once, or to allow something for a limited time.
| |
| | |
| Tokens are
| |
| * system-issued shared secrets
| |
| * known by only the endpoints that need to know
| |
| * typically completely random values (not e.g. derived keys)
| |
| * often time limited - the issuer forgets it after a time reasonable for the the mechanism it's being used in.
| |
| * often single use
| |
| | |
| The token values themselves have no meaning. The meaning comes from the issuer remembering it, for a specific purpose.
| |
| | |
| | |
| | |
| Upsides:
| |
| * if their use is snooped on, their one-time use means they aren't useful again
| |
| | |
| * if their issuing is snooped on, they're only useful for a limited time
| |
| : this is e.g. why password reset links time out after minutes to an hour - it is relatively unlikely someone else gets that information within that time (even with social engineering, etc)
| |
| | |
| * if are snooped on at any point, the values don't reveal anything
| |
| | |
| Downsides:
| |
| * bunches of exchange
| |
| | |
| * ...which itself is ideally already non-snoopable by some other means
| |
| | |
| | |
| | |
| | |
| | |
| You can set up token systems between related systems to manage what actions imply what grants to what entities.
| |
| For example:
| |
| * login token issued on login (e.g. hours), used purely to signify a user
| |
| * granting token, for specific
| |
| * session cookie, automatically issued based on login token (e.g. hour, tops)
| |
| : some systems use the login token ''as'' a session cookie. It doesn't reveal a lot more, but is still lazy.
| |
| | |
| When the user tries to access a secured application, the application will check for the presence of a granting token.
| |
| If found, it will issue a session token.
| |
| The session token exists for the duration of the user’s session with that application.
| |
| | |
| If not found, the user is redirected to the login server where they authenticate.
| |
| Then the user is issued a login token and a granting token and is redirected back to the application which uses the granting token as a basis for trust that the user has been authenticated.
| |
| | |
| | |
| | |
| Ticket granting ticket
| |
| http://en.wikipedia.org/wiki/TGT
| |
| | |
| | |
| Tokens make a lot of sense ''between'' systems,
| |
| in that it leads them to think about fine grained permission systems,
| |
| and most of their exchanges avoid any secret.
| |
| | |
| | |
| | |
| | |
| '''Login tokens''' represent "this specific user has previously successfully authenticated". (the server end will often also remember "authenticated at DATETIME" and "is valid until DATETIME").
| |
| | |
| Many systems will reuse this token, making it a '''session token'''.
| |
| | |
| Assuming an attacker steals such a token, they may well be able to act as you being logged in.
| |
| | |
| Ideally, there are actions that require ''more'' than that token, in particular:
| |
| * things that amount to stealing the the account (changing email address, changing password)
| |
| * authorizing external interactions (such as credit card purchases)
| |
| | |
| | |
| | |
| | |
| '''XSRF tokens'''
| |
| * One-use
| |
| * Named because their main purpose is to avoid XSFR attacks
| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| Practical details:
| |
| * forget/revoke after a time limit - both for safety and for manageability of the backing storage
| |
| * forget/revoke after use - whenever that's the point
| |
| | |
| | |
| -->
| |
| | |
| ===Delegated authentication / delegated access===
| |
| {{stub}}
| |
| <!--
| |
| | |
| Delegated authentication describes cases where website A can verify logins for websites/app B.
| |
| | |
| | |
| And instead of doing that by the user giving site/app B the login+password you would use on site A so that it can log in (which is bad for user privacy/security because it forces you to blindly trust site/app B)...
| |
| | |
| | |
| ...what happens is that (you make) site/app B initiate a "log in with site A", which happens with interactions purely with site A, and returns a token to site/app B.
| |
| Site B never sees passwords, it only ever sees
| |
| | |
| | |
| This idea be extended from just logins to
| |
| * allow website A to grant selective piece of information, like your home address (for checkout on shops).
| |
| : And it's website A that can say "are you sure?"
| |
| | |
| * allow specific users specific access
| |
| : like "let these people "
| |
| | |
| | |
| Means some other system handles authentication for your system,
| |
| and yours only really sees or stores the resulting "yes, that identity (that something else has verified) currently has a session here".
| |
| | |
| | |
| Universities and businesses often have a bunch of related systems they want to tie together,
| |
| in which case this is primarily done for integration: You have one basic identity there, instead of one on every little subsystem.
| |
| | |
| Maybe in single-sign-on style, it may not be and be one or two more steps.
| |
| | |
| | |
| '''Delegated authentication''' refers to just
| |
| | |
| Other terms refer to the granular sharing of information based on such systems.
| |
| | |
| | |
| | |
| On e.g. the internet, delegated comes in the form of "sign in with Oauth/google/facebook/twitter",
| |
| and it's more about one vouching for the other in a secure way.
| |
| | |
| It's not that they want your soul, it's the combination of:
| |
| * you likely already have logins (so identities) on one of these sites
| |
| :: for users, it saves the bother of creating yet another account
| |
| * the client site (or app) doesn't have to build its own authentication system
| |
| | |
| * the authenticating site can be granular in what it reveals
| |
| :: for it, that puts a limit on what it exposes, which is nice for privacy
| |
| :: for users, you will know when they ask and have to explicitly allow it, which is nice for privacy
| |
| | |
| * the client site (or app) doesn't need to see your password on
| |
| :: for users, it means you don't need to trust this site and its security practices, which is nice for both security and privacy
| |
| | |
| * it also eases ''partial'' access between users and between sites, like
| |
| : allow only person C to manage my calendar
| |
| : allow site A to see only my address information for easier checkout
| |
| :: for users, this means not having to give passwords to others, or full access another way, which is nice for both security and privacy
| |
| | |
| | |
| Building your own auth system is a hard to do in an actually secure way. For reference, various very large companies, large enough to know better, have made some textbook stupid mistakes. But even beyond such a checklist it's hard to do.
| |
| | |
| So instead of having a million sites each roll their own, means you know the average quality isn't great.
| |
| | |
| | |
| | |
| When only a few sites do the actual auth, that means you do,
| |
| and you can even know the client site can't know your password even if it wanted to.
| |
| | |
| | |
| Upsides
| |
| * breaking to any of the client sites does not expose any passwords/hashes (at best logged in sessions)
| |
| | |
| * individual sites need less work
| |
| | |
| * individual sites more secure
| |
| | |
| * it is easier to tell people "only put a password into the actual site it is for, and treat everything else as potentially bad actors".
| |
| | |
| | |
| | |
| Downsides:
| |
| * central auth sites become bigger targets for hackers (and potentially for legal entities)
| |
| | |
| * and higher impact, being a single point of failure for a lot of other sites
| |
| | |
| * you need to be able to strongly trust the auth sites
| |
| | |
| * you may be forced to use one of a few auth sites, when you don't care to
| |
| | |
| * if the auth site is broken into, the implications can be much wider (depends on details)
| |
| : (one reason why [[#Passwordless_login|passwordless login]] is a thing now)
| |
| | |
| | |
| See also:
| |
| * https://en.wikipedia.org/wiki/List_of_OAuth_providers
| |
| -->
| |
| | |
| ===Federated identity, Single Sign On===
| |
| {{stub}}
| |
| | |
| <!--
| |
| '''Federated identity''' usually refers to having a single identity(+authentication) that is usable across multiple systems, and the same.
| |
| | |
| Which is a thing you probably want when you you delegated auth based on that identity.
| |
| | |
| | |
| | |
| '''Shared authentication''' refers to multiple applications using the same means of authentication, e.g. checking against the same server, syncing some auth files.
| |
| | |
| Or trusting others to authenticate for them.
| |
| (Note that these systems still have to agree on identities)
| |
| | |
| | |
| For example,
| |
| * NIS
| |
| * business/university LDAP/kerberos servers,
| |
| * RADIUS
| |
| * Kerberos {{verify}}
| |
| * OpenID
| |
| * Windows Live ID
| |
| * IBM/Tivoli Global Sign-On
| |
| * Netegrity SiteMinder
| |
| * RSA ClearTrust (formerly Securant)
| |
| * PassGo, InSync (formerly Axent/Symantec)
| |
| * Courion, Password Courier
| |
| | |
| | |
| | |
| | |
| '''Single Sign On''' (SSO) is the idea that a single identity+authentication combination is usable on multiple related systems/sites (e.g. all within a business, university) without each doing their own authentication check.
| |
| | |
| For shared authentication to become SSO, you need a few more requirements, like
| |
| : identity management between these systems,
| |
| : the ability to (securely) pass authentication states around.
| |
| | |
| | |
| Note that a lot of apps won't merge with SSO as-is, because many will initially have their own identity+authentication.
| |
| | |
| Proper integration is nice, but may carry more considerations, and costs, that the tradeoff for everyone involved may actually land on "just log in every morning".
| |
| | |
| There are some intermediates, e.g. hacks around where the SSO logs you into an app-specific identity.
| |
| | |
| | |
| | |
| Upsides:
| |
| * fewer passwords to remember means less [[password fatigue]]
| |
| : and a potentially somewhat more convincing context for moderately strong passwords
| |
| | |
| * only rarely entering passwords makes it less likely for people to reveal their passwords
| |
| : (also one of the arguments for passwordless)
| |
| | |
| Downsides:
| |
| * the implications of a hack are wider
| |
| | |
| * availability is potentially more fragile
| |
| : which in some cases isn't acceptable. Consider a physical security door that reports 'server unavailable'
| |
| | |
| | |
| | |
| | |
| Some early SSO might simply transparently present credentials to other systems.
| |
| : You can imagine how that's convenient but not very secure
| |
| | |
| A more secure system would build on (secure) communication of login tokens.
| |
| | |
| | |
| | |
| Password sync -- multiple identities, same password across each. Useful when you want to present a single account but must have it work on different systems (same logical identity, separate accounts), for example unix and windows machines.
| |
| | |
| Arguably more of an implementation detail that you choose when deciding how/where to centralize
| |
| | |
| | |
| | |
| Web logon aggregators -- usually, you log into aggregator via first site; subsequent logins are handled transparently.
| |
| | |
| | |
| | |
| | |
| | |
| Sharing authentication alone is not necessarily single sign on. For example, having many clients use an institution's LDAP server independently is not SSO. Schemes like Windows Live ID, OpenID, and similar has many sites that can use the same authentication mechanism, but each site works separately - the sites that use it have no cooperation policies. Sites may choose to start cooperating in this way, but there are security implications (e.g. that of trust) to that.
| |
| | |
| | |
| A very simple form of (almost pseudo-)SSO is a domain cookie that all hosts in the domain use, by sharing a convention - and most likely some central means of verification (because without that, the system is likely easily exploitable).
| |
| | |
| Better system exchanges tickets/tokens.
| |
| | |
| | |
| | |
| | |
| http://technet.microsoft.com/en-us/library/cc512578.aspx
| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| http://en.wikipedia.org/wiki/Federated_identity
| |
| | |
| | |
| | |
| | |
| If you want the option off rate limiting, dynamic backoff and such, you often want to do so at as central a place as possible. This because you both avoid exposing way around the rate limiting, and because you want to avoid attacks
| |
| | |
| However, any client you open access to, e.g. an application, may be easily DoSed by trying many logins via it, since the extra step makes it less likely for the central server to judge the application from a bad user that has access to that application (this is controllable in a business, but hopeless on the web).
| |
| | |
| In this sort of situation, the central system should be able to give out the possibility of relaying that information, which you'ld like against a DoS attack, and sort of need against a DDoS attack (assuming the central system can be controlled). You'ld also want to do this selectively, since you might not trust all applications to report this correctly. Of course, if you don't trust the application you shouldnt give it anything, but you may still want a choice of what you give each application.
| |
| | |
| | |
| A single sign on / token system can be rather handy, because it centralizes the place that all logins happen. They also minimize the amount of connections that have to be secured and thereby the amount that may be left unsecured.
| |
| | |
| | |
| Of course, in reality you have protocols to use and conform to, so you can't/shouldn't get too custom.
| |
| | |
| -->
| |
| | |
| | |
| | |
| ===OTP===
| |
| <!--
| |
| On-Time Password (not to be confused with One-Time Pad) are passwords good for exactly one authentication attempt.
| |
| | |
| | |
| | |
| | |
| There are a few different ways to do that.
| |
| | |
| * "Send random number by SMS"
| |
| | |
| * Hardware tokens
| |
| | |
| * Soft tokens
| |
| : e.g. Authy, Google Authenticator,
| |
| | |
| * (numbered) list of passwords
| |
| | |
| | |
| Standards exist, including
| |
| * S/KEY (RFC 1760) [https://en.wikipedia.org/wiki/S/KEY]
| |
| * OTP (RFC 2289),
| |
| * HOTP (HMAC-based one-time password) (RFC 4226) [https://en.wikipedia.org/wiki/HMAC-based_one-time_password]
| |
| * TOTP (https://en.wikipedia.org/wiki/Time-based_One-Time_Password) (RFC 6238) [https://en.wikipedia.org/wiki/Time-based_One-Time_Password]
| |
| although most OTP / authenticator solutions are proprietary instead.
| |
| | |
| | |
| OTPs avoid replay attacks
| |
| | |
| OTPs are still vulnerable to MITM, and social engineering
| |
| | |
| | |
| | |
| | |
| One way to do this is to involve a counter in the process.
| |
| | |
| Assuming that the OTP generator is the only one that ever succeeds to authenticate,
| |
| this is another part of the process that is very hard for an external observer to estimate.
| |
| | |
| | |
| | |
| Yubikey
| |
| -->
| |
| | |
| | |
| ===On authenticators===
| |
| <!--
| |
| | |
| 'Authenticator' is not the best term, because by itself it only means 'thing that helps you authenticate'
| |
| | |
| | |
| | |
| It often points towards
| |
| * a hardware authenticator
| |
| : or rather the specific authentication exchange that it does, often made more secure by having a shared secret of some form
| |
| | |
| * an authenticator app
| |
| : doing the same in software
| |
| | |
| | |
| ...or anything else that amounts to 'something you have and is hard to figure out, that is generating passwords for you'.
| |
| | |
| | |
| | |
| '''How they work''' varies, but methods include:
| |
| | |
| Many amount to a separate device that does
| |
| * challenge-response ''based on'' a shared secret and a [[nonce]]
| |
| : requires input
| |
| : e.g. various banking tokens
| |
| | |
| | |
| | |
| * One-Time Passwords - Time based
| |
| : e.g. TOTP
| |
| : e.g. [https://en.wikipedia.org/wiki/RSA_SecurID RSA SecurID], Google Authenticator app
| |
| | |
| * One-Time Passwords - counter based
| |
| : e.g. HOTP
| |
| : e.g. Google Authenticator app
| |
| : counter is incremented on both sides on successful logins{{verify}}
| |
| :: makes it very clear someone else has managed to find out - because you will no longer be able to {{verify}}
| |
| : no exchange is necessary
| |
| | |
| | |
| Note that OTP ''may'' not be otherwise protected.
| |
| : because they are assumed to be 'something you have' and not protect against physical attacks
| |
| : means no exchange is necessary
| |
| : also makes it less bothersome to use
| |
| | |
| That said, for phone apps there ''is''
| |
| | |
| | |
| | |
| | |
| | |
| Whether it
| |
| is a physical device (we often call this a physical token, which isn't the clearest name), or
| |
| is an app
| |
| doesn't matter too much.
| |
| | |
| That is, in many cases, even knowing exactly how it works won't help an attacker,
| |
| without the shared secret, which ideally is impossible to derive from the device's responses.
| |
| | |
| | |
| | |
| | |
| -->
| |
| | |
| ===On passwordless login===
| |
| <!--
| |
| | |
| Given that passwords have issues, one proposal is to not use user-generated secrets at all.
| |
| | |
| | |
| | |
| Most proposals of passwordless actually amount to a shift away from what you know, and more towards what you have.
| |
| | |
| This of course presents a shift in risks,
| |
| ones that you ''need'' to teach your users to not be riskier,
| |
| but for a lot of localized uses (like businesses) can be pretty convenient.
| |
| | |
| | |
| | |
| Passwordless login typically amounts to 1-factor based on either
| |
| * or something you are -- typically biometrics like fingerprints, retinal scans, face or voice recognition
| |
| | |
| * something you have
| |
| :: cellular phone
| |
| :: smart card
| |
| :: OTP token or hardware token - any sort of hardware that you need to interact with
| |
| :: control over an account (like sending a token to phone or email)
| |
| ::: doing this ''without'' anything else has limited value
| |
| ::: and doing it with a password is just typical 2FA
| |
| | |
| | |
| In some ways, we have taken password+device 2FA and removed the password.
| |
| Or left it symbolically in, but don't really count it towards our
| |
| | |
| | |
| | |
| Keep in mind that biometrics were never a great idea ''as a single factor'',
| |
| because very few are distinguishing enough.
| |
| : either it has to be extremely strict (giving many false negatives)
| |
| : or it will probably accept lots of people (giving many false positives)
| |
| | |
| Fingerprints are one of the better options, but still come with many footnotes.
| |
| In general, assume that biometrics are useful as added difficulty, only.
| |
| | |
| | |
| | |
| A smart card or hardware token are a bad idea to use as a single one factor,
| |
| because '''theft of the device basically means theft of the identity'''
| |
| in ways that the system can never hope to detect.
| |
| | |
| (...not that it's much worse than "something you have that knows your password")
| |
| | |
| | |
| This is why the typical suggestion is
| |
| * a modern take on smart cards, like your phone providing a user key
| |
| : (that preferably is stored in TPM or similar)
| |
| : ideally with extra factors like a fingerprint check, otherwise it has all the issues of the above two
| |
| :: which is really 2FA with something you have and something you are.
| |
| | |
| | |
| Downsides:
| |
| * each host you need to log into needs extra hardware and integration.
| |
| : ...or imply that you're only partially passwordless
| |
| | |
| * if your phone is stolen, you cannot log in at all in the meantime, and re-registering may be a pain
| |
| | |
| -->
| |
| | |
| ===On multi-factor authentication===
| |
| {{stub}}
| |
| | |
| <!--
| |
| | |
| '''Multi-factor authentication''' (MFA) a.k.a. '''N-factor authentication'''
| |
| means you need to provide multiple things as proof of identity.
| |
| | |
| Typically meaning 2-factor (a.k.a. 2FA) because more than two is tedious.
| |
| | |
| Two factors then are usually "something you have, and something you know",
| |
| because for most uses, that's strong enough, and more is deemed too much bother for too little extra security.
| |
| | |
| | |
| | |
| A '''"something you know"''' is often a password.
| |
| | |
| Upsides:
| |
| : cannot be given without you knowing - just not telling it to other people goes a long way
| |
| | |
| However, downsides include
| |
| : brute-forceability
| |
| : someone can duplicate by overhearing it - it is reusable indefinitely (no [[forward security]])
| |
| : that you cannot easily know it has been compromised
| |
| : [http://news.bbc.co.uk/2/hi/technology/3639679.stm easily be traded for chocolate]).
| |
| | |
| | |
| | |
| A '''"something you have"''' has more varied forms, including
| |
| * a [[smart card]] (often to contain a key)
| |
| * your phone ('type the code we're about to SMS to you')
| |
| * your private key (e.g. in SSH)
| |
| * online banking systems - details vary, but many involve a physical thing
| |
| | |
| | |
| Upsides:
| |
| * requires more effort to steal - if someone has to physically travel to where you are, that removes all 'random attempts on the internet' worries. Someone would have to specifically targeting you, ''and'' be interested enough to put in the effort.
| |
| | |
| * optionally, it is also noticeable - if someone has to e.g. steal a hardware token, you will notice the next time you try to use it
| |
| and can take appropriate action.
| |
| | |
| | |
| Downsides:
| |
| * you may not notice it being stolen for some time while
| |
| | |
| * doesn't protect against physical attacks
| |
| | |
| | |
| | |
| Part of the point is that one factor reduces the downsides of the others. For example,
| |
| * a 'something you have' factor means someone cannot start brute forcing a password without having that thing.
| |
| * a 'something you have' factor means overhearing the password doesn't get you in
| |
| | |
| | |
| | |
| | |
| | |
| 2-factor auth is often explained in response against passwords.
| |
| | |
| You can argue against passwords, for example that:
| |
| * if password guessing gets easier and faster, we have to choose ever more complex passwords - this is impractical
| |
| * password guessing on password hashes has gotten easier as computers have gotten faster
| |
| * password guessing is sometimes easy on networked systems since you can do so without much limit (things like exponential backoff are pretty effective, but not always implemented, per-user means you may lock the user out, per-IP means that distributed attacks can get a whole bunch of attempts)
| |
| | |
| | |
| | |
| | |
| Upsides:
| |
| * a weak password in a two-factor system is less of a problem, in that an attacker needs the other factors, and often needs them ''first''.
| |
| | |
| * weakness in one factor (e.g. even a password on a sticky note) is less serious when you keep the factors separated
| |
| : ...though the sticky note basically removes a factor.
| |
| | |
| | |
| Downsides:
| |
| * can be a lot of bother to use
| |
| : What you may well ''expect'' of your banking system would be a pain for your laptop.
| |
| | |
| * may give a false sense of security
| |
| ** not all systems we well designed (e.g. against man-in-the-middling)
| |
| ** weakness in one factor can effectively remove a factor
| |
| | |
| | |
| Depends:
| |
| * should implement revocation, in response to theft of the thing you have
| |
| | |
| | |
| | |
| | |
| | |
| | |
| '''On "something your computer knows"'''
| |
| | |
| So, critically speaking, that's not strictly either.
| |
| | |
| I may know the passwords too, but the point was always that they were in my head ''only''.
| |
| Meaning, among other things, that they cannot be extracted without me knowing.
| |
| | |
| | |
| If my browser knows my passwords, that is no longer true.
| |
| | |
| Because anyone who sits down can use everything, without having to know everything.
| |
| | |
| That is technically still something I have, in that only someone sitting in my chair gets this.
| |
| | |
| But this is effectively one-factor, where (when syncing) some cases of having any one of my devices is enough.
| |
| If my phone syncs my browser passwords, and a website does 2FA with my phone, then my phone is both of these two factors, which defeats the point.
| |
| | |
| | |
| A good and separate password manager is at least in theory something that ''acts'' as if it is separated (like a smart card),
| |
| in that when locked, it is encrpyted data that is meaningless without an external factor (master password, or authenticator).
| |
| | |
| Browser auth tends not to do this. It works as long as it's running, which is always.
| |
| | |
| | |
| | |
| | |
| | |
| '''On biometrics'''
| |
| | |
| Even without addressing the ability to fake, most biometrics are, in isolation, not unique distinguishing enough.
| |
|
| |
| As such, they cannot be proof of identity, i.e. they cannot be authentication.
| |
| | |
| They may well be useful as an added factor, ''not'' because it's identifying,
| |
| but because it's useful to filter attempts, and may act as a deterrent.
| |
| | |
| | |
| -->
| |
| | |
| ===On TPM auth===
| |
| <!--
| |
| | |
| One of the things TPM hardware can do for you is
| |
| | |
| | |
| | |
| | |
| -->
| |
| | |
| ==Auth systems - practical considerations==
| |
| | |
| ==Notes on implementations (and parts of them)==
| |
| | |
| ====LDAP====
| |
| LDAP is often used for authentication (via its binding mechanism, or sometimes via a proxy user that has wide access).
| |
| | |
| See also:
| |
| * [[LDAP]]
| |
| * http://en.wikipedia.org/wiki/LDAP
| |
| | |
| ====Kerberos====
| |
| {{stub}}
| |
| <!--
| |
| | |
| | |
| Kerberos KDC (Key Distribution Center)
| |
| | |
| -->
| |
| | |
| See also:
| |
| * http://en.wikipedia.org/wiki/Kerberos_%28protocol%29
| |
| | |
| ====RADIUS====
| |
| {{stub}}
| |
| | |
| A framework that can be used for authentication, authorization and accounting.
| |
| <!--
| |
| | |
| Authenticates against a local file, PAP, CHAP, EAP, and modern systems added other means, such as SQL databases, Kerberos, LDAP, or Active Directory servers.
| |
| | |
| Used in some types of WiFi security, and various supporting networking (various dial-in, broadband, and more)
| |
| -->
| |
| | |
| See also:
| |
| * http://en.wikipedia.org/wiki/RADIUS
| |
| <!--
| |
| http://tools.ietf.org/html/rfc2866
| |
| -->
| |
| | |
| | |
| ====*nix systems====
| |
| {{stub}}
| |
| | |
| * PAM (Pluggable Authentication Modules), commonly used in OSes such as Linux, Mac OSX, a number of BSD variants {{comment|(the others usually use BSD Auth)}}, Solaris, AIX, HP-UX and more.
| |
| ** There is also a distinction between Linux PAM (used in linux) and OpenPAM, used in FreeBSD, NetBSD and Mac OS X Snow Leopard, and some linux distributions.
| |
| | |
| * BSD Auth (used by some BSD variants)
| |
| | |
| * [[NSS]] (Name Service Switch)
| |
| | |
| <!--
| |
| PAM is an API to a set of pluggable modules. The idea is usually to make the method of authentication separate and external to the app, so that it can be configured by admins.
| |
| | |
| | |
| X/Open Single Sign-on (XSSO)
| |
| | |
| -->
| |
| | |
| See also:
| |
| * http://en.wikipedia.org/wiki/Pluggable_Authentication_Modules
| |
| * http://en.wikipedia.org/wiki/OpenPAM
| |
| * http://en.wikipedia.org/wiki/Name_Service_Switch
| |
| * http://en.wikipedia.org/wiki/BSD_Authentication
| |
| | |
| ====Microsoft windows components====
| |
| {{stub}}
| |
| | |
| * NTLM ('NT Lan Manager'), mostly for SMB (see [[samba]])
| |
| | |
| * MS-CHAP, mostly for remote access
| |
| | |
| * GINA (Graphical Identification and Authentication), which is the graphical login window.
| |
| : GINA is basically a replacable executable; a common alternative is Novell's replacement GINA, and also of interest is [http://pgina.org/ pGina], a project that lets you authenticate against many different things.
| |
| | |
| | |
| See also:
| |
| * http://en.wikipedia.org/wiki/NTLM
| |
| * http://en.wikipedia.org/wiki/MS-CHAP
| |
| * http://en.wikipedia.org/wiki/Graphical_Identification_and_Authentication
| |
| | |
| * http://www.pgina.org/
| |
| | |
| ====SIP authentication====
| |
| {{stub}}
| |
| http://www.voip-info.org/wiki/view/SIP+Authentication
| |
| | |
| ====Athens, OpenAthens====
| |
| {{stub}}
| |
| | |
| https://en.wikipedia.org/wiki/OpenAthens
| |
| | |
| ====RSA SecurID====
| |
| {{stub}}
| |
| | |
| A two-factor system using a physical token that periodically generates a new code, based on a seed.
| |
| | |
| Relies on synchronizing the token with the login server's clock.
| |
| | |
| | |
| | |
| http://en.wikipedia.org/wiki/SecurID
| |
| | |
| ==Online delegated auth==
| |
| {{stub}}
| |
| | |
| * Shibboleth
| |
| | |
| * OpenID, usable for any system that wishes to support them (see also [[OpenID notes]])
| |
| | |
| * OAuth, for (service) APIs, bears similarities to OpenID {{verify}} [http://oauth.net/] [http://hueniverse.com/2007/10/beginners-guide-to-oauth-part-i-overview/]
| |
| | |
| * Windows Live ID (Hotmail, Messenger, Xbox LIVE, others), previously known under various names including the word passport
| |
| | |
| * Google
| |
| ** Note that Google exposes their accounts via OAuth / OpenID {{verify}}
| |
| | |
| | |
| <!--
| |
| Early days, authentication was restricted to a site.
| |
| | |
| | |
| These days it's common to do things to get another site to provide an identity, and say that identity is authorized.
| |
| | |
| The way this is done looks a bit complex, particularly if you're building one, or even just hooking into an API.
| |
| | |
| At the core it's mostly basic concepts. It looks more complex because of
| |
| * separation by design.
| |
| : e.g. site A doesn't need to know your password when you authenticate at site B
| |
| | |
| * avoiding the risk of unsecured channels
| |
| : e.g. avoiding replay attacks
| |
| | |
| | |
| This is often explained from the view of what needs to happen, which reads as quite complex because
| |
| avoiding unnecessary knowledge of other parts/sites is interesting/complex.
| |
| | |
| -->
| |
| | |
| | |
| | |
| | |
| | |
| | |
| ===OAuth notes===
| |
| {{stub}}
| |
| <!--
| |
| | |
| OAuth is an open standard for access delegation.
| |
| | |
| OAuth version 1 was succeeded by OAuth2.
| |
| Most everyhing talks 2. If they talk 1, it's typically for backwards compatibility reasons.
| |
| | |
| | |
| OAuth is not a (full) authentication protocol,
| |
| | |
| | |
| | |
| | |
| Bearer token
| |
| https://stackoverflow.com/questions/25838183/what-is-the-oauth-2-0-bearer-token-exactly/25843058
| |
| | |
| | |
| -->
| |
| | |
| See also:
| |
| * https://en.wikipedia.org/wiki/OAuth
| |
| * RFC 5849 (in 2010) is OAuth 1.0
| |
| * RFC 6749 (in 2012) is OAuth 2.0
| |
| | |
| ===OpenID notes===
| |
| {{stub}}
| |
| ====Short version====
| |
| See [http://simonwillison.net/2006/openid-screencast/ this video], it's pretty clear on the basics.
| |
| | |
| | |
| | |
| | |
| ====What it is====
| |
| OpenID lets you have an identity and relevant authentication for it stored/executed ''remotely to the sites that use it''.
| |
| | |
| Which lets you use one identity, backed by a single OpenID provider, in many sites that want to use OpenIDs
| |
| (which act as OpenID clients to the provider for each OpenID identity).
| |
| | |
| It lets you use a single identity for sign-on to many unrelated websites.
| |
| It mostly solves cross-site identity verification - to the degree that clients can trust the OpenID provider,
| |
| because the system is comparable to an orgnisation vouching for people you personally don't know.
| |
| | |
| | |
| Technically, OpenID servers are identity brokers and verifiers.
| |
| | |
| OpenID is decentralized in general, though each identity is centralized in that it implies a particular OpenID provider (exactly that?{{verify}}). The OpenID itself is URL-based, which is ''how'' an openID implies a provider, which is how an OpenID client knows what server to contact for verification.
| |
| | |
| As far as the side wishing for verification is concerned, the exchange is roughly:
| |
| * site using OpenID: "Hey, this guy ''particularopenid'' is trying to log in. Do you agree that's them?"
| |
| * OpenID server: "Hmm, ''particularopenid''? Let's see, I'll check. Yup, I say that's them." (or, of course, the negative answer)
| |
| Note that the check and login happen on the openID provider - the OpenID client never sees the login information, or means of login.
| |
| | |
| | |
| The check proves that the identity described by the URL that ''is'' is indeed verified. {{comment|(There is a bunch of security detail about going from site to site that side of things can for the most part be fairly simply trusted.)}}
| |
| | |
| | |
| Just how much that server's verification actually means to the client side, however, depends on the trust you place in the openID provider.
| |
| | |
| ====What it isn't====
| |
| | |
| It does not really deal with trust - the only thing you really get is the information on whether a specific exchange succeeded.
| |
| | |
| | |
| Implicit (and pre-configured) trust in a system is always a bad idea (human trust is often one of the weakest links in a security system).
| |
| To get back to the vouching-for-someone analogy: you would likely accept a good friend vouching for someone else, but probably not someone who's opinion you've come to disagree with, or a stranger. If some company vouches, you would still make some quick risk assessments and consider how their policies have worked out in the past.
| |
| | |
| | |
| A login in a decentralized login (OpenID or otherwise) is limited by:
| |
| | |
| * The verifier's trustability.
| |
| : Consider an openID server <tt>spam.com</tt> that answers 'yes' to each and every request that comes in.
| |
| | |
| * Certain implementation details
| |
| : OpenID allows setup of aliases, such as using a short domain name as an OpenID (by making it point to one). This means that this identity can change, e.g. when I lose the domain and someone else registers it.
| |
| :: OpenID allows clients to check whether it is verifying the same ''actual'' ID as before, but they have to actually do so to be secure against this.
| |
| | |
| Still, OpenID does make a number of things harder to fake.
| |
| For example, if you got a comment or account request from spock.oid.example.com, and I can (informally) check that the person I'm thinking of indeed owns that openID, and that oid.example.com is trustworthy, that means they signed it.
| |
| | |
| ====Basic usage details====
| |
| Signing up for an identity means a provider hands you a single URL that represents your identity.
| |
| | |
| | |
| This identity itself implies the site at which it the identity can be verified, which means login at a site you've never been before at involves:
| |
| * typing your identity, such as <tt>example.myopenid.com</tt>
| |
| * You get forwarded to the site that can verify this identity -- in this case myopenid.com
| |
| * you log into your openid provider,
| |
| * it tells you the new site wants access,
| |
| * you allow it,
| |
| * you get sent back to the new site
| |
| To the casual observer, it's a username/password deal, just at a central site.
| |
| | |
| | |
| OpenID has two main uses that I've noticed. The first is being the login step for an account elsewhere. This may well imply choosing a screen name there that is unrelated. This use is purely private, for my own ease of login.
| |
| | |
| The other is leaving a comment that is provably mine, say, on a blog (such as on livejournal -- except I have an account there anyway)
| |
| | |
| | |
| | |
| ====Identity delegate on a page====
| |
| There are several openID providers, but you may not like some company's name in your ID. While you could technically run your own openID service, that's not very practical.
| |
| | |
| Something that is a lot easier is using a specific website -- usually a domain you own, to keep it short, or perhaps the URL to your main blog -- that you have control over.
| |
| | |
| | |
| Consider that losing control over that domain or website means that a different identity may eventually sit at the same openID url. If you stop owning that site, it is not guaranteed another identity won't be put there.
| |
| | |
| In fact, this is a feature too: since you delegate to a real openID service, you can change the delegate to another OpenID when for some reason you want to swith accounts, say, your openID service disappears.
| |
| | |
| <!--
| |
| This does not equal identity theft, but it's similar. That identity cannot log into the things you created from there{{verify}}, but if you relied on people seeing this as your 'real' identity, well, you have a problem.
| |
| -->
| |
| | |
| ====OpenID providers====
| |
| Some services imply an openID. For example, Livejournal users have an openID, period. AOL is implementing openIDs, and microsoft said it would too. Using one of these may be simpler. You can of course have several openIDs.
| |
| | |
| As to provider services, there are many. See http://openid.net/wiki/index.php/Public_OpenID_providers
| |
| | |
| | |
| ====Sites you can use OpenID on====
| |
| Also a big list, and growing quickly. See https://www.myopenid.com/directory
| |
| | |
| | |
| <!--
| |
| http://www.gnucitizen.org/blog/openid-a-security-story/
| |
| -->
| |
| | |
| ====Unsorted====
| |
| | |
| http://www.openid-ldap.org/ (OpenID provider based on LDAP authentication)
| |
| | |
| | |
| [[Category:Security and privacy]]
| |
| | |
| | |
| | |
| ===Identity providers===
| |
| <!--
| |
| An identity provider (IdP) is a site you trust,
| |
| manages identities for [[principals]] (users, mostly),
| |
| and lets you use
| |
| | |
| Auth as a service.
| |
| | |
| | |
| IndieAuth (OAuth2)
| |
| | |
| OpenID (OAuth)
| |
| | |
| | |
| SAML
| |
| | |
| | |
| https://en.wikipedia.org/wiki/IndieAuth
| |
| | |
| | |
| -->
| |