Difference between revisions of "Security notes / Identification, authentication, authorization"

From Helpful
Jump to: navigation, search
m
m (→‎On multi-factor authentication)
Line 670: Line 670:
 
means you need to provide multiple things as proof of identity.
 
means you need to provide multiple things as proof of identity.
  
−
Typically meaning 2-factor (a.k.a. 2FA), in the form of "something you have, and something you know",
+
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.
 
because for most uses, that's strong enough, and more is deemed too much bother for too little extra security.
 +
  
  
Line 712: Line 715:
 
* a 'something you have' factor means overhearing the password doesn't get you in
 
* a 'something you have' factor means overhearing the password doesn't get you in
  
−
 
−
 
−
 
−
 
−
'''On biometrics'''
 
−
 
−
Even without addressing the ability to fake, most biometrics are not distinguishing enough.
 
−
 
−
As such, they cannot be proof of identity, i.e. they cannot be authentication.
 
−
 
−
However, they may 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.
 
  
  
Line 755: Line 746:
  
 
Depends:
 
Depends:
−
* should implement revokation, in response to theft of the thing you have
+
* 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.
 +
 
  
 
-->
 
-->

Revision as of 13:34, 25 January 2022

Security related stuff.

Practical


Theory / unsorted



how to do a login system badly
how to do encryption badly
encrypted connections
data-at-rest encryption

Identity, authentication, and authorization

Auth systems - setup considerations

Local authentication

Centralized authentication

Shared authentication

Tokens and tickets

Delegated authentication / delegated access

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, somay have incorrect bits. (Feel free to ignore, or tell me)

Federated identity, Single Sign On

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, somay have incorrect bits. (Feel free to ignore, or tell me)



OTP

On authenticators

On passwordless login

On multi-factor authentication

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, somay have incorrect bits. (Feel free to ignore, or tell me)


On TPM auth

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:

Kerberos

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, somay have incorrect bits. (Feel free to ignore, or tell me)

See also:

RADIUS

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, somay have incorrect bits. (Feel free to ignore, or tell me)

A framework that can be used for authentication, authorization and accounting.

See also:


*nix systems

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, somay have incorrect bits. (Feel free to ignore, or tell me)
  • PAM (Pluggable Authentication Modules), commonly used in OSes such as Linux, Mac OSX, a number of BSD variants (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)


See also:

Microsoft windows components

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, somay have incorrect bits. (Feel free to ignore, or tell me)
  • 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 pGina, a project that lets you authenticate against many different things.


See also:

SIP authentication

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, somay have incorrect bits. (Feel free to ignore, or tell me)

http://www.voip-info.org/wiki/view/SIP+Authentication

Athens, OpenAthens

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, somay have incorrect bits. (Feel free to ignore, or tell me)

https://en.wikipedia.org/wiki/OpenAthens

RSA SecurID

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, somay have incorrect bits. (Feel free to ignore, or tell me)

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

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, somay have incorrect bits. (Feel free to ignore, or tell me)
  • Shibboleth
  • OpenID, usable for any system that wishes to support them (see also OpenID notes)
  • OAuth, for (service) APIs, bears similarities to OpenID (verify) [1] [2]
  • 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)





OAuth notes

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, somay have incorrect bits. (Feel free to ignore, or tell me)

See also:

OpenID notes

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, somay have incorrect bits. (Feel free to ignore, or tell me)

Short version

See 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. (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 spam.com 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 example.myopenid.com
  • 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.


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


Unsorted

http://www.openid-ldap.org/ (OpenID provider based on LDAP authentication)

Retrieved from "https://helpful.knobs-dials.com/index.php?title=Security_notes_/_Identification,_authentication,_authorization&oldid=75111"