Rich Freeman on 2 Jun 2017 07:33:56 -0700

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] Password manager OneLogin hacked

On Fri, Jun 2, 2017 at 10:08 AM, Rich Kulawiec <> wrote:
> Recall the discussion about LastPass six months ago?
> On Mon, Jan 09, 2017 at 07:53:05AM -0500, Rich Kulawiec wrote:
>> On Sat, Jan 07, 2017 at 09:46:21PM -0500, Tim Allen wrote:
>> > I've been using LastPass for a while, and am dreading the day when they
>> > inevitably get hacked and I have to change all my passwords.
>> You *should* dread that day, especially if it's already history.
> And -- quite predictably -- we now have this:
>         Password manager OneLogin hacked, exposing sensitive customer data

It seems like this article isn't terribly well-written.

Looking at the company it doesn't actually look like they actually
sell a "Password Manager" per se despite the title of the article.
They are an IAM provider, providing single-sign-on services.

That is a fairly different line of business than something like
LastPass and works fundamentally differently.

Now, it does sound like they have a "Secure Notes" feature which can
be used as a password manager "lite" - it wouldn't actually auto-fill
passwords.  I'm not sure how those were implemented, but it sounds
like it isn't actually secured using a user-owned private key only.

I imagine most of their customers just use them for IAM, and while the
breach is a big problem it wouldn't actually result in a leak of any
secondary passwords.  Their users would need to have credentials
re-issued, and companies would need to invalidate any certificates
used by the IAM solution.  When you outsource IAM this is one of the
risks you take, but you face many of the same risks if you do it
yourself, and there are a lot of benefits with IAM.

> Of course we only know about the hacks that operators care to report,
> which is a subset of the set they know about, which is a subset of the set
> their employees know about, which is a subset of the set that has happened,
> which is a subset of the set that has and will happen.

Sure, but the same is true of your own internal security breaches.  If
you're the one handing out tokens to third parties how do you know
that somebody hasn't been handed a token they shouldn't have been
given?  How do you know if somebody has broken into your own
authentication database, if you have thousands of outsiders on your
network?  IAM providers don't tend to get used by mom-and-pop shops.

Philadelphia Linux Users Group         --
Announcements -
General Discussion  --