I can answer the last two questions.
The answer is because the work to make that not happen just hasn't been
done yet. Those things are low hanging fruit but at the same time
they're not massive problems either. With our current workloads our days
are exercises in triaging problems. These just haven't been high enough
They are on the list of things to get to though. So I can only say that
hopefully sometime soon I can make the changes to support both
auto-focus on the Blackboard jump page and support for the referring
service provider to supply the username to the WebAuth login page.
Actually, I've just made the change on the Blackboard jump page as it's
pretty trivial. I'll try to take a look at the WebAuth changes in the
next few weeks.
On 6/16/15 13:21 , Ernie Buford wrote:
> This thread inspires several questions...
> What if "the cloud provider" is UVM? (one likely scenario is keeping a
> password database file on UVM network storage)
> Is this LastPass episode reason to be happy about having chosen to use a
> different password keychain? (probably not as they all must have
> Why must I click in the one available input field before I can type my
> netID into that field in order to login to Blackboard? ... And why does
> that page then take me to yet another page where I have to enter my netID?
> OK, the last 2 questions weren't inspired by this thread, but I had to
> throw them in.
> On 6/16/2015 12:50 PM, J. Greg Mackinnon wrote:
>> I have to say whether you are using two-factor authentication or not,
>> I would be very wary of putting something as sensitive as a password
>> keychain under the full control of a cloud provider. I am sure the
>> developes at LastPass have the best intentions, but we really only
>> have their word that they are not doing something stupid and evil with
>> your passwords.
>> I recognize that most folks likely are storing mostly personal
>> (non-UVM) passwords in LastPass, but I suspect that storing UVM
>> passwords in a cloud provider might construe a violation of University
>> network security policy. Maybe. I would be interested to hear the
>> ISO weigh in on this subject.
>> -J. Greg Mackinnon | ETS Systems Architecture and Administration | x68251
>> On 6/16/2015 12:16 PM, Joe Parent wrote:
>>> LastPass supports multifactor authentication with Duo Security
>>> <https://www.duosecurity.com/>, as seen on their two-factor
>>> page, https://helpdesk.lastpass.com/multifactor-authentication-options.
>>> Duo Security is one of the methods weíve been testing for use on
>>> PeopleSoft two-factor, and it works nicely. You can setup Push, SMS,
>>> or land-line options so you donít always need your mobile phone to
>>> make it work.
>>> See https://helpdesk.lastpass.com/multifactor-authentication-options/duo-security.
>>> The technical details about just how/when LastPass performs
>>> two-factor are a little lacking, but I did find this in the FAQ
>>> How does LastPass securely identify a trusted computer?
>>> When you check the option to mark a device as "trusted", we
>>> create a random, unique identifier for that device. We then
>>> encrypt that ID using Windows "crypt protect data" functions,
>>> which encrypt the ID based on the user's credentials. This
>>> ensures that another user would not be able to decrypt it. We
>>> then store the encrypted ID on the hard drive, and store a hash
>>> of the ID on our server in a database. This is passed back after
>>> the user tried to login - the hash is compared with the hash of
>>> the ID after it has been decrypted (after the user enters their
>>> email address + master password). If they match, LastPass then
>>> skips the prompt for a multifactor authentication and logs in the
>>> For mobile devices, LastPass uses a randomly generated id that is
>>> stored in secure phone storage.
>>> From that I surmise that you only need to go through the two-factor
>>> process once per browser to make it a trusted device, although the
>>> above sounds like (on Windows computers anyway) it doesnít matter
>>> which browser you use. Not sure how thatíd correlate on a Mac, but I
>>> imaging a similar method is used. Itís also possible that youíd only
>>> need to go through the two-factor when you enter your master password
>>> to unlock your vault. I was going to set it up on mine and I can
>>> report back later.
>>> Joe Parent
>>> ETS Client Services, UVM
>>> From: Andrew Hendrickson <[log in to unmask]
>>> <mailto:[log in to unmask]>>
>>> Reply-To: Technology Discussion at UVM <[log in to unmask]
>>> <mailto:[log in to unmask]>>
>>> Date: Tuesday, June 16, 2015 at 11:23 AM
>>> To: Technology Discussion at UVM <[log in to unmask]
>>> <mailto:[log in to unmask]>>
>>> Subject: Re: LastPass was breached
>>> So, which of the lengthy list of two part authentication methods
>>> do people recommend?
>>> I have little experience but would like something that wonít hit
>>> me up for every login, only if something changes (unfamiliar
>>> device, remote IP).
>>> I donít have cell service at home, so having to use the phone to
>>> authenticate every time is going to be an issue. Unless that
>>> authentication also works over wifi under iOS?
>>> On Jun 16, 2015, at 8:12 AM, Geoffrey Duke
>>> <[log in to unmask] <mailto:[log in to unmask]>> wrote:
>>> Analysis from Ars Technica:
>>> Hack of cloud-based LastPass exposes hashed master passwords
>>> Users: Change your master password and enable 2-factor
>>> authentication immediately.
>>> ... Ars resident password expert Jeremi Gosney said the
>>> real-world risks the breach posed to end users was minimal.
>>> He based his assessment on the LastPass response to the
>>> breach and the system that was in place when it happened.
>>> Full article:
>>> -----Original Message-----
>>> From: Technology Discussion at UVM
>>> [mailto:[log in to unmask]] On
>>> Behalf Of Jacob Beauregard
>>> Sent: Monday, June 15, 2015 7:07 PM
>>> To: [log in to unmask] <mailto:[log in to unmask]>
>>> Subject: LastPass was breached
>>> "We want to notify our community that on Friday, our team
>>> discovered and
>>> blocked suspicious activity on our network. In our
>>> investigation, we
>>> have found no evidence that encrypted user vault data was
>>> taken, nor
>>> that LastPass user accounts were accessed. The
>>> investigation has shown,
>>> however, that LastPass account email addresses, password
>>> server per user salts, and authentication hashes were
>>> Andrew Hendrickson
>>> CAS IT Administrator
>>> UVM, College of Arts & Sciences
>>> [log in to unmask] <mailto:[log in to unmask]>
>>> To submit a request for service please use: