HP3000-L Archives

April 2014, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Gilles Schipper <[log in to unmask]>
Reply To:
Gilles Schipper <[log in to unmask]>
Date:
Sat, 12 Apr 2014 23:24:26 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (211 lines)
Good question.

I  only mention that lastpass was affected because I saw it I included in a list of important and/or popular sites affected by Heartbleed.

Now I'll have to search where I saw it.

Gilles Schipper 
Sent via mobile
416-702-7900

> On Apr 12, 2014, at 11:23 PM, Richard Corn <[log in to unmask]> wrote:
> 
> Given that lastpass pw's are encrypted on your device, transmitted and stored at lastpass in encrypted form, how would heartbleed compromise them?
> 
> 
> 
> 
> Richard Corn
> Software Devices LLC
> 
> 
> 
> -------- Original message --------
> From: Gilles Schipper <[log in to unmask]> 
> Date: 04/12/2014 8:13 PM (GMT-08:00) 
> To: [log in to unmask] 
> Subject: Re: OT OpenSSL-1.0.1 Heartbeat exploit named heartbleed 
> 
> 
> I use lastpass and was concerned that they were one of the sites that WAS affected by the Heartbleed bug.
> 
> They appear to have eliminated their vulnerability but clients' passwords could have been compromised prior to very recently.
> 
> Gilles Schipper 
> Sent via mobile
> 416-702-7900
> 
> > On Apr 12, 2014, at 10:45 PM, Mark Wonsil <[log in to unmask]> wrote:
> > 
> > Lastpass.com
> > 
> > You have one master password and it will generate high entropy passwords.
> > They are encrypted locally and stored at lastpass.com.
> > 
> > It will also check sites for HeartBleed vulnerability and let you know. It
> > can store encrypted notes as well.
> > 
> > They have an enterprise edition that will generate passwords for users too.
> > 
> > Mark W
> >> On Apr 12, 2014 10:19 PM, "James B. Byrne" <[log in to unmask]> wrote:
> >> 
> >>> On Sat, April 12, 2014 20:02, Gilles Schipper wrote:
> >>> And should we be using your same random-generated secure password for
> >> ALL of
> >>> our sites - or a separate one for each.
> >>> 
> >>> If the latter, presumably we'd need much thicker wallets.
> >> 
> >> Well, personally I have just five or so separate passwords for use on
> >> public
> >> websites.  For banks and financial institutions I use the same
> >> high-security
> >> randomly generated password.  Except for one bank that only permits letters
> >> and digits, go figure.
> >> 
> >> For other places like eBay and Paypal, I have a different high-security
> >> password and a different login ID.  For Credit Card accounts another
> >> different
> >> high-security password and user ID.  These five or so I keep on a single
> >> slip
> >> of paper in my wallet and a copy in an envelope in my safe at home.
> >> 
> >> For places that I need to have account access security but I do not trust
> >> (a
> >> certain high-profile online ebook and merchandise retailer for example) I
> >> use
> >> disposable passwords.  When I want to log on I ask for a password reset,
> >> generate a high-security password, change the account to that, log in, do
> >> my
> >> work, log out and forget it.
> >> 
> >> For those sites that do not use https and yet require a user login, a most
> >> appalling case of appearance before substance, I use a satirical password.
> >> For sites that use https but are simply BBs or web forums or use poor
> >> ciphers,
> >> I use a slightly less satirical password that is somewhat more robust.
> >> 
> >> But this hodge-podge of logins and passwords is why I feel that X.509
> >> certificates on electronic memories such as so-called 'smart cards' or
> >> 'flash'
> >> memory cards is the only presently available technology to handle the need
> >> for
> >> secure authentication.  You then keep your private keys and public
> >> certificates on a physical device separate from any computer system and
> >> connect them physically to any single device only long enough to establish
> >> secure communication between that device and another.  Once the two
> >> endpoints
> >> are connected then you physically remove the memory device containing the
> >> keys.
> >> 
> >> All of your private keys on that device are themselves encrypted using one
> >> randomly generated high security pass-phrase of at least 25 characters and
> >> you
> >> keep that pass-phrase only in hard copy format so that it simply cannot be
> >> snooped. Unless of course you let a key-logger get onto your personal
> >> digital
> >> device, in which case nothing will work to protect you.
> >> 
> >> In our case I made the decision to employ a single login for all of our
> >> services so that our employees only have to know one user ID and one
> >> password.
> >> Said user ID and password are provided by us and not picked by the user.
> >> However, besides using a password provided by us they also all must
> >> connect to
> >> our business systems via ssh through a single gateway sshd server. This
> >> applies to LAN and WAN access so the technique used is identical whether
> >> working on-site or remotely.
> >> 
> >> Out-of-band confirmation, so-called two-factor authentication, is another
> >> technique presently in use to increase reliability of challenge-response
> >> authentication.  The problem being that the meta-data that this provides to
> >> any potential attackers is extremely valuable in itself.  It can be very
> >> interesting to some people to know when you login to certain sites and
> >> where
> >> you are located when you do so.
> >> 
> >> As I write this via an https webform I am connected to our internal webmail
> >> service through our sshd gateway system located at our premises via an ssh
> >> tunnel.  Once you receive this message then the message routing appears to
> >> begin at our webmail host and nowhere else.  Wherever I was when I composed
> >> the message appears in the ssh login records on our sshd server which is
> >> where
> >> the httpd logs on the webmail host show as the point of origin for the
> >> webmail
> >> https session.  This makes it really hard to determine my originating
> >> traffic
> >> patterns without actually obtaining root access to at least two separate
> >> hosts
> >> simultaneously.  It does not help with traffic analysis where the the
> >> endpoint
> >> is concerned but it does obscure to some extent where I am located at any
> >> given moment.
> >> 
> >> When I am searching for things on the web I now use the Tor Browser and
> >> either
> >> DuckDuckGo or StartPage.  If you have a Google account, log on to it, go to
> >> tools and look at the complete record of all the Google searches you
> >> performed, by date, while logged onto your Google account. All of them.
> >> Since
> >> 2006.  Anything there that you would feel, shall we say awkward,
> >> explaining to
> >> your parents, kids, wife or employer?  They sell that stuff.  Or they are
> >> compelled to cough it up on demand to whenever the authority-du-jour asks
> >> for
> >> it.
> >> 
> >> Communication security on the Internet is, in my opinion, never anything
> >> more
> >> than a illusion.  Traffic analysis is far more revealing than the contents
> >> of
> >> many messages.  The details of the contents of ten or so messages between
> >> you
> >> and a collections agency will reveal little more of interest to a snooper
> >> than
> >> the fact of those ten message do by their very existence.   How would you
> >> feel
> >> if the existence of those messages were revealed to your spouse, your
> >> neighbour, your employer, or colleagues, or potential clients, or insurance
> >> company, or religious community, or social club?
> >> 
> >> What would you do if someone threatened to reveal the existence of such
> >> messages to some sensitive third party unless you complied with some
> >> request?
> >> What if it was an AIDS clinic? A mental health provider? An LGBT support
> >> group?  How much is your privacy worth to you then?  And recall that those
> >> conducting such surveillance do not have to read your email, although they
> >> most certainly are. All that they need know is that it was sent by you, the
> >> approximate number of communications, and the nature of the parties it was
> >> sent to or received from.
> >> 
> >> Unless you can hide the protocols and the routing as well as the message
> >> then
> >> a determined adversary is going to find a weakness and penetrate your
> >> system.
> >> It is just a question of how long and what form it will take.  Some
> >> passwords
> >> just make it a little more difficult than others.  Just like locks on your
> >> house.  None of them will keep out a professional but some of them make the
> >> amateurs go somewhere else.
> >> 
> >> --
> >> ***          E-Mail is NOT a SECURE channel          ***
> >> James B. Byrne                mailto:[log in to unmask]
> >> Harte & Lyne Limited          http://www.harte-lyne.ca
> >> 9 Brockley Drive              vox: +1 905 561 1241
> >> Hamilton, Ontario             fax: +1 905 561 0757
> >> Canada  L8E 3C3
> >> 
> >> * To join/leave the list, search archives, change list settings, *
> >> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
> > 
> > * To join/leave the list, search archives, change list settings, *
> > * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
> 
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2