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

David Tomaschik david at systemoverlord.com
Thu Mar 28 21:26:55 EDT 2013


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.


>
> 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"?  Sure, if LearnStreet wanted me to put my
Github username and password into their site, I'd never do it.  But I
don't.  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.

Also, what "verification and authentication methods" would you recommend?
 I'd really like to see an open standard that uses cryptographic smart
cards (with opt-in only key escrow) to access data and sites.  But short of
that, usernames and passwords are just plain broken for your average user.


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


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


>
> > What constitutes a "security breach" in one environment might be
> > expected, even normal behavior in another environment altogether.
>
> Please give an example of this.
>
>
> > 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.
>
> Personally, I'd tell learnstreet to take a hike, just less politely.
>
> Cheers,
> Robert~




-- 
David Tomaschik
OpenPGP: 0x5DEA789B
http://systemoverlord.com
david at systemoverlord.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20130328/4af8ea98/attachment-0001.html>


More information about the Ale mailing list