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

[Robert Reese]

Hello David,

Thursday, March 28, 2013, 9:26:55 PM, you wrote:

> On Thu, Mar 28, 2013 at 6:08 PM, Robert Reese <ale at sixit.com>wrote:

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


> This is true, but it also provides *one provider* who you need to
> trust with security, not every site.  You can run that provider
> yourself with OpenID.  So, OpenID (or centralized authentication in
> general) reduces the attack surface, but increases the damage from a successful attack.

I don't trust even *one provider*.  Which is why I have a unique login for each and every site.  One gets compromised, then I just fix that one problem.

Further, OpenID is the DMA's wet dream.  No thanks!



>>  And NOBODY gets my login credentials for ANY OTHER SITE.  Period. 
>> End of story.  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 what you mean here: what is the "the requirement of
> third-party login credentials"? 

Requiring the login credentials of another service/site/provider.

>  I log in to Github, and when I want to log in to
> some other site, they can use OAuth2 to ask GitHub to please verify
> that the request I am sending them comes from me.  The other site never sees my Github password.

I don't trust OAuth2, and I don't trust the transaction between the two.


> Also, what "verification and authentication methods" would you
> recommend?

The most common is to simply send a verification link to the email address you set up.  That is usually proof enough that you are who you say you are when you sign up for something.  Or send SMS to a cellphone that was entered when the account was created or modified at some point when you had control over it.  Even using a PGP implementation to directly receive a token - something encrypted by the sender's public key, perhaps - that is signed by your private key and verified by your public key.  There are many types of authentication, but most are not needed.

There really is no reason for a site to outsource its responsibility for security.  That tells me either they don't take security seriously, or are incapable of providing sufficient security.

 
>>  I'm not sure I trust LastPass, either.
> Good, don't trust anything you can't verify.  I personally believe
> convenience of using lastpass outweighs security risk of using
> lastpass.  But nobody's forcing you to use it. 

Convenience, a.k.a. laziness, is probably the biggest part of the problem our society faces with electronic security.  People don't understand the risks, and don't care as they don't think it is a big deal if something happens, and if it does it isn't happening to them, so they don't care.  It is why virtually every insurance company and financial company openly flaunts its compliance requirements, and why I'm about to sue a closing attorney.


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

> Which sites don't get authentication data?  The SSO provider or the
> site whose resources you want to access?  If they use OpenID or
> OAuth, they wouldn't get a password from your provider.  Here's the
> specifications if you haven't read them:
> https://tools.ietf.org/html/rfc6749,
> https://openid.net/specs/openid-authentication-2_0.html. 


I don't trust that the authorization cannot be intercepted.  I don't trust the intermediary.  I don't trust sites to not have snooping scripts which are designed to grab the authentication data.  I don't trust that sites don't or won't create a phishing SSO authentication.  Also, I've seen too many bad implementations to not trust that the system is implemented properly at any site.  I don't trust that sites will maintain the ability to ensure forged tokens aren't passed to them, allowing someone to pose as me.

Further, I absolutely don't want the tracking abilities of SSOs.  Sites which use SSOs aren't interested in security as much as they should be, but a good percentage definitely want part of that information pie.

By the way, that openidexplained.com site?  What a complete and utterly fetid piece of crapola that site is; I am so very tempted to set up a debunking site and calling out most of that site's content as mythical.  It's only saving grace is that it is created by a couple of guys and not OpenID; it is sponsored, probably, by OpenID but not is OpenID's direct property.

Cheers,
Robert~