Weekly Edition
Return to the Security page
| |||||||||||||
Security quotes of the week
Firefox 4 should be treated as a member of the new breed in that regard,
and have 5 as its security update.
-- Robert
Kaiser
Actually, we are prolonging the security support for 4 and later, it's not just a minimum of six months any more, now it's "forever", just that the security updates always bring features and a new "version" as well. ;-)
I drafted a very short message (perhaps the first was too long?) and sent it to the four, once again from their own accounts: Really wasn't kidding about the insecurity thing. I won't send another message after this -- it's up to you to take your security seriously. You're at the [XYZ Street] Starbucks on an insecure connection, and absolutely anyone here can access your account with the right (free) tool.
-- Gary
LosHuertos runs an experiment with Firesheep
Twenty minutes passed, and all four were still actively using Facebook.
Having known about this problem
since 2003, a "fix" was applied in 2010 for firefox 4 which attempts to
identify credit card numbers in forms and not store them in the form
history. Great, now what about all the other data it is storing some of
which is just as sensitive as credit card numbers, if not more so ? If
credit card details get mis-used, liability is usually on the credit card
company, but not so for social security numbers, bank account numbers,
etc...
-- Daniel
P. Berrangé looks into Firefox's form data storage
Bitcoin raises untested legal concerns related to securities law, the Stamp
Payments Act, tax evasion, consumer protection and money laundering, among
others. And that's just in the U.S. While EFF is often the defender of
people ensnared in legal issues arising from new technologies, we try very
hard to keep EFF from becoming the actual subject of those fights or
issues. Since there is no caselaw on this topic, and the legal implications
are still very unclear, we worry that our acceptance of Bitcoins may move
us into the possible subject role.
-- EFF
stops accepting Bitcoin donations
Yesterday we made a code update at 1:54pm Pacific time that introduced a
bug affecting our authentication mechanism. We discovered this at 5:41pm
and a fix was live at 5:46pm. A very small number of users (much less than
1 percent) logged in during that period, some of whom could have logged
into an account without the correct password. As a precaution, we ended all
logged in sessions.
-- Dropbox drops
authentication for a few hours(Log in to post comments)
Security quotes of the week Posted Jun 23, 2011 10:29 UTC (Thu) by job (guest, #670) [Link]
This Dropbox situation, where an authentication failure meant every password was accepted, should be an eye-opener for all cloud migrations. You really must have a price tag on all kinds of failure and know exactly where the liability is.
Security quotes of the week Posted Jun 23, 2011 11:46 UTC (Thu) by jengelh (subscriber, #33263) [Link]
One more reason to not store your data in the cloud and essentially hand over control. But I guess there are always some uneducatables.
Security quotes of the week Posted Jun 23, 2011 22:19 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Oh? And this situation can't happen in a non-cloud environment?
I've seen very uncloudy things like unsecured MSSQL installations _dozens_ of times by now. At least with clouds these sorts of SNAFUs are highly visible.
Security quotes of the week Posted Jun 23, 2011 23:58 UTC (Thu) by robert_s (subscriber, #42402) [Link]
Using the cloud, there's nothing you can do about it, no matter how security clued-up you are.
You have to just "assume" that the people running your cloud service aren't a bunch of clowns.
Security quotes of the week Posted Jun 27, 2011 15:06 UTC (Mon) by nye (guest, #51576) [Link]
The whole *point* of form data storage is to remember your personal information. Complaining about that seems like complaining that water is wet.
(PS. In the UK the only thing you can do with a person's bank details is transfer money to them or set up a Direct Debit. Direct Debits are strictly controlled and companies which want to accept DDs have to be vetted and take liability for any abuse. Really the only truly sensitive piece of information is my e-mail password, which is exactly the kind of thing form remembering was invented for.)
Security quotes of the week Posted Jun 27, 2011 17:50 UTC (Mon) by BlueLightning (subscriber, #38978) [Link]
I'm not sure it's quite that simple in the UK:
Security quotes of the week Posted Jun 29, 2011 11:03 UTC (Wed) by nye (guest, #51576) [Link]
>I'm not sure it's quite that simple in the UK:
Typical overblown media shenanigans.
All he had to do was ask for the money back and they were legally obliged to provide it, no questions asked, or lose the ability to take Direct Debits ever again. The only reason he didn't is that that would have been PR suicide given that he asked for it in the first place.
Let's think about what that case really says:
Security quotes of the week Posted Jun 28, 2011 19:21 UTC (Tue) by k8to (subscriber, #15413) [Link]
Well I think it's a fair point to highlight that there's some extremely inconsistent attempt at policy implemented here. Which itself suggests that the feature is poorly considered.
How about giving the user control over what is and isn't remembered in forms?
How about adding some hints to forms that allow the html to suggest that some fields probably shouldn't be remembered to default the browser ui?
How about some evaluation of how the data is retrieved? Can javascript pull them up? Maybe the user should have to explicitly request loading of the data?
I'm certainly not an expert on this feature, but those are all things to look at, in my view.
Security quotes of the week Posted Jun 30, 2011 11:19 UTC (Thu) by nye (guest, #51576) [Link]
>How about giving the user control over what is and isn't remembered in forms?
That's a fair point, though only a small minority of users would ever take advantage of the option
> How about adding some hints to forms that allow the html to suggest that some fields probably shouldn't be remembered to default the browser ui?
Doesn't it already have that? I know from filling doesn't seem to work on some sites, including some I use regularly, and it drives me nuts. This should be combined with point one so that it can be overridden to 'yes'.
> How about some evaluation of how the data is retrieved? Can javascript pull them up? Maybe the user should have to explicitly request loading of the data?
This is the most interesting point to me. I would tend to say that the form should fill in automatically but any controls filled in should be marked as tainted until the user explicitly chooses to type in them. A tainted control would, for example, return an empty string when queried for its contents. Possibly something like this is already done?
|
|||||||||||||