[ale] help - how do I log into learnstreet without ...

[Michael B. Trausch]

On 03/28/2013 09:08 PM, Robert Reese wrote:
>> A lot of web applications are going with sign-in over the Web
>> through various providers.  Now, I would love to see sites support
>> Google, Twitter, Facebook, etc., but also support plain Jane
>> generic OpenID as well, along side those.  OpenID is a safe and
>> usable SSO method on the Internet.
> 
> I am strictly opposed to OpenID.  That is a really, really bad idea
> in my opinion: Compromised once, compromised everywhere.

On the other hand, the situation is far better than the one where a user
uses the same password on a large number of Web sites.

I'll admit that I have done that in the past.  A good number of my
accounts were compromised and I had a big mess to clean up because ONE
provider had my password in plaintext, and I'm not exactly hard to find
on the Internet, either.  That makes me a relatively visible target on
the Internet.

There are two types of single-sign-on systems:

 * Classic ones, built around Kerberos, which are highly secure as long
   as the KDC itself is secure.  These systems are quite excellent, as
   with proper configuration settings, compromise is something that can
   be _very_ easily mitigated.  If I find that an account has been
   compromised, I can invalidate all sessions by nothing more than a
   simple password reset---tickets are then not going to be serviceable
   anymore, and effectively access is revoked to the whole network that
   uses it, including Web applications and so forth.

 * Internet-based ones, such as OpenID, Facebook-Connect, and other
   often ad-hoc systems.  Some are built around usernames and passwords;
   some are built around SSL client-side certificates, and others use
   different mechanisms of action entirely.  I'd only want to use an
   OpenID provider (e.g., server that has my identity information on it
   and will authenticate me to other sites on the Internet) that I have
   a relatively high trust for; e.g., Launchpad is a good place for
   that.

   But the _WONDERFUL_ thing about OpenID is this:  You can run your own
   OpenID provider!  Using whatever rules you want!  You can even do
   something like use Kerberos tickets to authenticate to your OpenID
   provider, and that will then allow you to authenticate with the
   OpenID consumer on a third-party site---securely.

To sum up:  Compromised once, fixed once, everywhere.

> And NOBODY gets my login credentials for ANY OTHER SITE.  Period.
> End of story.

So, OpenID should be just dandy for you, since you don't give up
credentials to third party sites with it.  That was the whole point of
OpenID; I'd strongly, strongly suggest you do some research on how
federated identity management systems work in general, but specifically
since we're talking about OpenID, you should really read through that
and study it to learn how it works.  I should think that it would be
very likely that once you know how it works at a lower level, you'll
change your views on it.

OpenID _increases_ security on the Internet.  Roll your own OpenID
server, use whatever secure authentication technologies you want on it,
and use it to proxy your identity (NOT your credentials) to the rest of
the Internet.  Passwords aren't even required; as I said before, you can
use SSL/TLS client certificates or even Kerberos to perform the
authentication between you and the OpenID server you have setup, and
those credentials aren't transmitted elsewhere.

Lost your unencrypted client certificate and key pair?  That's fine.
Revoke and reissue.

Password in Kerberos has been compromised?  That's okay, too:  reset the
password, disable the account, assess the damages, fix it once, and move
forward with life.

Everyone seems to forget that security isn't just about keeping things
from others:  it is also about reducing downtime and mitigating threats
that cannot always be kept out using preventative measures.  Users can,
do, and will use bad passwords.  Users can, do and will use the same
password on multiple Web sites and multiple networked services, and even
on multiple networks.  Federated identity management systems such as
OpenID provide a viable, effective answer to these bad practices that we
don't usually have the power to control.

I can't speak for anyone else on this list, but I know that when I walk
onto a client site, I have to fit any solutions that I have into their
currently existing administrative framework.  For example, one client we
used to have refused to store passwords safely, refused to implement
sane password policies, and refused to do anything that would increase
security (such as limiting the lifetime of a user session to something
less than unlimited), in the name of "convenience".  I can suggest good
solutions which do not decrease convenience until I am blue in the face,
but the rest of the world has done a really wonderful job teaching
people that security is inconvenience.

It's really fscking hard to fight back against that.

> In fact, I support legislation outlawing the
> requirement of third-party login credentials; there are plenty of
> verification and authentication methods that work just fine without
> handing over authentication data to a third-party.

I'm not sure why that's even a topic here; nobody is talking about
handing authentication data anywhere.

>> I use stronger passwords than probably most people on this list do
>> for most things, but I don't much need a bookkeeping method for my
>> passwords because I leverage SSO technologies where I can.  They
>> make my life way easier, at a minimal cost, and I never actually
>> have to share my authentication data with third party sites that I
>> sign into that way. It's win/win.
> 
> Lose/lose, when that SSO is compromised.  Nor do I believe that those
> sites don't get authentication data; every single one of them I've
> seeen asks for username and password.

As an alternative to those who don't use OpenID.  At least on every site
where I have seen generic OpenID _consumer_ functionality implemented.

I have an account on Launchpad, for example.  I use it to authenticate
to Stack Overflow and that network of sites, as well as a few other
places.  I use OpenID to reduce the impact of and mitigate compromise.
That's what it is there for.

>> What constitutes a "security breach" in one environment might be 
>> expected, even normal behavior in another environment altogether.
> 
> Please give an example of this.

I did already, and you quoted it even!
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv

>> We can all agree that, for example, plaintext communication is
>> unsafe across the Internet for many things.  But on an
>> intranetwork, particularly a very small and isolated intranetwork,
>> there is little need to increase complexity just to have
>> communications be encrypted on that network.  Internetwork links
>> transited over the public Internet, though, that's another story
>> altogether.
> 
> Apples and oranges.  The discussion has nothing to do with intranets,
> which is supposed to be a walled garden with respect to the outside.

Well, yes, there should be firewalls and the like.  But intranetworks in
large enterprises should be treated as just as hostile as the Internet
because not every person can trust every other person in such an
environment.  Something the size of my business doesn't need to do that
(yet).

So, I've now refined the example a bit, but really, the concept applies
to virtually anything.  Streaming stock data in plaintext isn't a
security vulnerability if it's 20 minutes delayed, which is why everyone
does it that way.  But streaming realtime stock data, that is very
valuable information that systems use to make realtime decisions and
thus you pay through the nose for it (and they consider the
retransmission of that to be a security breach).

> Personally, I'd tell learnstreet to take a hike, just less politely.

To each their own.  Remain blissful!

	--- Mike

-- 
Michael B. Trausch, President
Naunet Corporation

Telephone: (678) 287-0693 x130
Toll-free: (888) 494-5810 x130
FAX: (678) 287-0693

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://mail.ale.org/pipermail/ale/attachments/20130329/7d1cba5c/attachment.sig>