[kwlug-disc] Heartbleed affected sites
unsolicited
unsolicited at swiz.ca
Mon Apr 14 20:20:55 EDT 2014
That's my point - it DOES hurt to change it.
Time consumption to do so, and time wasted later trying to remember what
you changed it to -this- time. Or chase down how you recorded it (e.g.
browser cache / password lookup). Now repeat for every other place
you've been encouraged to (pointlessly) change your password as well,
which of course you did because the media knows all.
Now multiply by number of users out there. And again by number of
accessing devices. What a waste of resources.
This is my issue - all very well to take corrective action to known and
quantified issues, but not so to send everyone to chase their tail
everywhere 'just in case.' The I.T. industry could and should do a
better job for its users. I.T. is a tool, not an end in itself. The tail
should not be wagging the dog.
-----
Your note makes me wonder ... wherefore OpenID on all this? (In the
sense of being a single password.) And I wonder if (some day?) OpenID
could go change all your passwords for you, and the user need only
change their OpenID password.
Given your note, I'm guessing that makes some sense to you too, if two
factor authentication is used for OpenID there. [OpenID == (set of
OpenID like services, which seems to more and more include gmail accounts)]
On 14-04-14 11:12 AM, Darcy Casselman wrote:
> I still contend that your Instagram password is the last thing you need to
> worry about from Heartbleed.
>
> https://twitter.com/CP24/status/455686305305751553
>
> But sure, it doesn't hurt to change it.
>
> Although, as I write on my blog, relying on a shared secret for your
> identity has been proven again and again to be insufficient. Setting up
> two-step verification with a one-time password is the best way right now to
> avoid having your credentials stolen from a server, regardless of how an
> attacker gets that information.
>
> http://flyingsquirrel.ca/index.php/2014/04/12/enable-two-factor-authentication/
>
> Darcy.
>
>
> On Sat, Apr 12, 2014 at 4:15 PM, unsolicited <unsolicited at swiz.ca> wrote:
>
>> Yep, had caught those aspects.
>>
>> Keyword being 'potential'. Which is only to say, with the media all
>> running around with their heads cut off, and only a small subset of such
>> services you use WITH impacted servers AND real potential harm to you at
>> exposure IF you have an account worth messing around with more lucrative
>> than others, there's a lot of FUD out there.
>>
>> Which is not to say you won't be impacted, nor that it won't hurt when you
>> are ... but it's not EVERYWHERE for EVERYTHING.
>>
>> I don't dispute the problem is discerning when it really matters.
>>
>> I'm only irritated that they put out carte blanche 'change everything'
>> 'just in case'. This, my industry (I.T.), should be able to be rather more
>> surgical, and less 'there MAY be risk, better safe than sorry'.
>>
>> Considering the time and expense and potential exposure most everyone is
>> being told to expend. Most of which is pointless for lack of real exposure.
>> That's my issue - lots of FUD and noise, most of it, just noise, and we all
>> have better things to do.
>>
>>
>>
>> On 14-04-12 12:51 PM, Khalid Baheyeldin wrote:
>>
>>> Heartbleed extracted whatever happened to be in memory at the time. That
>>> can be passwords or hashes or anything else.
>>>
>>> It is non-specific, but a determined attacker can potentially glean some
>>> info with persistence.
>>>
>>> Also, because the attacker does not need to complete a connection that
>>> would be logged (e.g. HTTP, ...etc.), this makes the attacks untraceable
>>> with the usual logs (e.g. web server).
>>>
>>> This is what makes it scary: potential information disclosure, and non
>>> traceablility.
>>>
>>>
>>> On Sat, Apr 12, 2014 at 4:29 AM, unsolicited <unsolicited at swiz.ca
>>> <mailto:unsolicited at swiz.ca>> wrote:
>>>
>>> That's over simplistic.
>>>
>>> You can't extract a password that isn't there.
>>>
>>> *IF* it is even in the packet you get.
>>>
>>> *IF* it was being exploited at the time.
>>>
>>> *IF* you are of interest to them.
>>>
>>> *IF* they are interested in doing damage to that provider of services.
>>>
>>> Lot of IFs. Lot of FUD.
>>>
>>> What's being protected?
>>>
>>> Will you know?
>>>
>>> Will you care?
>>>
>>> Not saying now that exploit known they wouldn't run with it.
>>>
>>> But patching is simplistic.
>>>
>>> I take your point about SSL keys - IF it was in the data returned.
>>>
>>> But with properly isolated systems, it should only be the front end
>>> impacted. On the assumption that nobody inside your firewall is
>>> exploiting it.
>>>
>>> Lots of IFs all around.
>>>
>>> But I take your point.
>>>
>>>
>>>
>>> On 14-04-11 05:44 PM, Bob Jonkman wrote:
>>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> If your router is accessible from the WAN port via http then you
>>> have
>>> more urgent problems than Heartbleed.
>>>
>>> If a site has both http and https then there's no (new)
>>> vulnerability
>>> with http, but a Heartbleed attack on https can still extract
>>> passwords and other info.
>>>
>>> To extract a password from an http session a bad guy needs to be a
>>> man-in-the-middle, or sniffing the network (remember Firesheep?).
>>> To
>>> extract a password with Heartbleed an attacker only has to
>>> initiate an
>>> https session.
>>>
>>> - --Bob.
>>>
>>>
>>>
>>> On 14-04-11 05:35 PM, Khalid Baheyeldin wrote:
>>>
>>> But, wouldn't Heartbleed be an issue, only if you use SSL on
>>> the
>>> site? For example, if you have OpenWRT/Tomato/DD-WRT and
>>> logging
>>> via http (not https), then there is no exploit via OpenSSL?
>>>
>>>
>>> On Fri, Apr 11, 2014 at 3:26 PM, Bob Jonkman
>>> <bjonkman at sobac.com <mailto:bjonkman at sobac.com>>
>>>
>>> wrote:
>>>
>>> If you're using a tool to check for Heartbleed
>>> vulnerabilities, be
>>> sure to check the Web interface on your router and/or modem as
>>> well.
>>>
>>> I'm not sure if router vendors are on top of this, but
>>> according
>>> to ssltest.py my Tomato/MLPPP Version 1.25-mp3alpha6 (from
>>> http://fixppp.org ) is not vulnerable, nor my Thomson
>>> Speedtouch
>>> modem with firmware 6.1.0.5
>>>
>>> Also, somebody asked me how safe these vulnerability checking
>>> tools are, especially the online and Javascript-based ones.
>>> What's
>>> to say they're not merely displaying "all is well", and
>>> actually
>>> compiling a list of vulnerable sites for later exploitation?
>>>
>>> --Bob.
>>>
>>>
>>> On 14-04-08 12:06 PM, Khalid Baheyeldin wrote:>
>>>
>>> You can use this python tool ssltest.py to check
>>> if your
>>> servers are vulnerable:
>>>
>>> $ wget -O ssltest.py
>>> "http://pastebin.com/raw.php?__i=WmxzjkXJ
>>> <http://pastebin.com/raw.php?i=WmxzjkXJ>"
>>> $ python ssltest.py example.com <
>>> http://example.com>
>>>
>>>
>>>
>>>
>>> On 14-04-11 10:51 AM, CrankyOldBugger wrote:
>>>
>>> Mashable has a list going of sites affected by
>>> Heartbleed:
>>>
>>> http://mashable.com/2014/04/__
>>> 09/heartbleed-bug-websites-__affected/
>>>
>>> <http://mashable.com/2014/04/
>>> 09/heartbleed-bug-websites-affected/>
>>>
>>>
>>>
>>> Don't forget to add Canada Revenue (and most other government
>>>
>>> sites) to your list of passwords to change!
>>>
>>>
>>>
>>>
>>> Bob Jonkman <bjonkman at sobac.com <mailto:bjonkman at sobac.com>>
>>> Phone: +1-519-669-0388 <tel:%2B1-519-669-0388>
>>>
>>> SOBAC Microcomputer Services http://sobac.com/sobac/
>>> http://bob.jonkman.ca/blogs/
>>> http://sn.jonkman.ca/__bobjonkman/
>>>
>>> <http://sn.jonkman.ca/bobjonkman/>
>>> Software --- Office & Business Automation ---
>>> Consulting
>>> GnuPG Fngrprnt:04F7 742B 8F54 C40A E115 26C2 B912 89B0 D2CC
>>> E5EA
>>>
>>>
>>>
>>> _________________________________________________
>>> kwlug-disc
>>> mailing list kwlug-disc at kwlug.org
>>> <mailto:kwlug-disc at kwlug.org>
>>> http://kwlug.org/mailman/__listinfo/kwlug-disc_kwlug.org
>>> <http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _________________________________________________ kwlug-disc
>>> mailing
>>> list kwlug-disc at kwlug.org <mailto:kwlug-disc at kwlug.org>
>>> http://kwlug.org/mailman/__listinfo/kwlug-disc_kwlug.org
>>> <http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org>
>>>
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.4.14 (GNU/Linux)
>>> Comment: Ensure confidentiality, authenticity, non-repudiability
>>>
>>> iEYEARECAAYFAlNIYh8ACgkQuRKJsN__LM5erCjgCfZAuLyG8v83bORUxPxTvs
>>> __14m+
>>> r8kAoInhKmR99uQBN2cIt+__2KY3xq4KMl
>>> =6dTX
>>> -----END PGP SIGNATURE-----
>>>
>>>
>>>
>>> _________________________________________________
>>> kwlug-disc mailing list
>>> kwlug-disc at kwlug.org <mailto:kwlug-disc at kwlug.org>
>>> http://kwlug.org/mailman/__listinfo/kwlug-disc_kwlug.org
>>> <http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org>
>>>
>>>
>>>
>>> _________________________________________________
>>> kwlug-disc mailing list
>>> kwlug-disc at kwlug.org <mailto:kwlug-disc at kwlug.org>
>>> http://kwlug.org/mailman/__listinfo/kwlug-disc_kwlug.org
>>> <http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org>
>>>
>>>
>>>
>>>
>>> --
>>> Khalid M. Baheyeldin
>>> 2bits.com <http://2bits.com>, Inc.
>>>
>>> Fast Reliable Drupal
>>> Drupal optimization, development, customization and consulting.
>>> Simplicity is prerequisite for reliability. -- Edsger W.Dijkstra
>>> Simplicity is the ultimate sophistication. -- Leonardo da Vinci
>>> For every complex problem, there is an answer that is clear, simple, and
>>> wrong." -- H.L. Mencken
>>>
>>>
>>> _______________________________________________
>>> kwlug-disc mailing list
>>> kwlug-disc at kwlug.org
>>> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
>>>
>>>
>>
>> _______________________________________________
>> kwlug-disc mailing list
>> kwlug-disc at kwlug.org
>> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
>>
>
>
>
> _______________________________________________
> kwlug-disc mailing list
> kwlug-disc at kwlug.org
> http://kwlug.org/mailman/listinfo/kwlug-disc_kwlug.org
>
More information about the kwlug-disc
mailing list