×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

21 Financial Sites Found To Store Sensitive Data In Browser Disk Cache

samzenpus posted about 10 months ago | from the out-in-the-open dept.

Security 118

An anonymous reader writes "The LA Times mentions that after visiting well known sites such as ADP, Verizon Wireless, Scottrade, Geico, Equifax, PayPal and Allstate, sensitive data remains in the browser disk cache despite those sites using SSL. This included full credit reports, prescription history, payroll statements, partial SSNs, credit card statements, and canceled checks. Web servers are supposed to send a Cache-Control: no-store header to prevent this, but many of the sites are sending non-standard headers recognized only by Internet Explorer, and others are sending no cache headers at all. While browsers were once cautious about writing content received over SSL to the disk cache, today, most do so by default unless the server specifies otherwise."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

118 comments

IE wins (0, Troll)

Power Rangers 2000 (2957585) | about 10 months ago | (#44058023)

recognized only by Internet Explorer

So IE is the only browser that cares about your privacy and doesn't store sensitive data in its cache. Got that. I just wish that more browsers would be like IE. But after all, Microsoft has always greatly cared your privacy - unlike Google and their snooping does.

Re:IE wins (1)

UltraZelda64 (2309504) | about 10 months ago | (#44058109)

Yep, being the very first company involved in the Prism surveillance system, I'm sure Microsoft knows this "snooping" Google does on your privacy well...

Reading fail (2, Insightful)

wonkey_monkey (2592601) | about 10 months ago | (#44058301)

but many of the sites are sending non-standard headers recognized only by Internet Explorer

Still, you got paid, what do you care?

Re:Reading fail (0)

Power Rangers 2000 (2957585) | about 10 months ago | (#44058393)

And who says other browsers cant implemented the same headers?

Re:Reading fail (2)

wonkey_monkey (2592601) | about 10 months ago | (#44058619)

Most of them do implement the standard ones. That's why they're called standards.

The fail is your monkeyboy. (2, Interesting)

DaveV1.0 (203135) | about 10 months ago | (#44059209)

Maybe you should try reading the second link from the summary [securityevaluators.com] and take a look at the standard heads [w3.org]. What you would find is that the standard is "no-cache". Chrome and Firefox use the non-standard "no-store". But, guess which browser supports three different headers, and the only one to actually support the standard? IE.

Re:The fail is your monkeyboy. (2)

operagost (62405) | about 10 months ago | (#44061235)

No-store is standard and, in this context, would have the same effect as no-cache. Go home, Ballmer, you're drunk.

Re:Reading fail (0)

Anonymous Coward | about 10 months ago | (#44059095)

Hmmm, Microsoft probably would have something to say... Your implementing OUR Proprietary Headers!?
lawsuits galore....

And that my friends (3, Interesting)

mitcheli (894743) | about 10 months ago | (#44058045)

would be why I have no Internet Cache. Disabled immediately after install. What is also concerning is the myriad of other client side data storage techniques (to include the newer ones with HTML5) Firefox does a pretty good job with plugins and Chrome to some extent as well, but with Apple refusing to allow addons in their Webkit and Microsoft doing whatever it does with IE, this issue is likely to get worse as technology continues to evolve.

Re:And that my friends (2, Informative)

Power Rangers 2000 (2957585) | about 10 months ago | (#44058053)

Apple refusing to allow addons in their Webkit

Apple's browser's name is Safari. WebKit is the rendering engine.

Re:And that my friends (2)

AK Marc (707885) | about 10 months ago | (#44058135)

"Their webkit" could be translated as "Safari, Apple's Webkit-based browser." So I don't see your correction as changing the meaning. Maybe because so many here know the correction you made, that only those reading with the "goal" of proving someone wrong would deliberately read it so obtusely.

Re: And that my friends (1)

Anonymous Coward | about 10 months ago | (#44058521)

Chrome was based on WebKit up until a month ago so up until a month ago Chrome didn't allow plugins to address this? Pedantic may be pedantic, but wrong is still wrong.

Re:And that my friends (0)

Anonymous Coward | about 10 months ago | (#44059765)

With ISP's moving more and more to pay per byte you may want to revisit that idea.

I have HUGE amounts of cache (disk is cheap). I have upwards of 15-40% hit rates. 20-40% are served from the local cache and the remaining 15-20% is served from a local squid server. That is for just 3 people. Think about that, I use about 20-30 gig a month in web data. I only go to the web for 10-15 gig. Meaning I am not wasting my BW cap on stuff I already downloaded. Also another perk is my web browsing is sped up by 2-10%.

Also with transparent caching you would have 0 idea I even did it unless you dug into it. Many ISPs do this and you have no control over it. If you are using a phone browser you can almost bet your isp is doing it. Also with transparent caching I can change the headers before you even see them. Big scary warnings in the config files about doing it. But nothing stopping me from doing.

Even a modest 10-20 meg cache would get you a hit rate of 15-20%.

Re:And that my friends (0)

Anonymous Coward | about 10 months ago | (#44060207)

with Apple refusing to allow addons in their Webkit

WTF?

WebKit is open source and LGPL/BSD licensed, and non-Apple entities, including and especially Google, have been contributing to it for the better part of a decade.

Or perhaps you're talking about Safari, which does allow extensions [apple.com]?

And what does any of this have to do with storing client-side data?

"Despite Using SSL" (3, Insightful)

Anonymous Coward | about 10 months ago | (#44058061)

What does SSL have to do with what happens to the data once it's local?

I understand that most people are clueless, but this is slashdot still, right? I haven't stumbled upon some other site on which to dig up TFA (not that I've read it).

Re:"Despite Using SSL" (2, Informative)

Anonymous Coward | about 10 months ago | (#44058089)

As the summary says, browsers were once cautious about writing content received over SSL to the disk cache. The use of SSL provides a hint to the browser that the data is sensitive, but now browsers choose -- despite the use of SSL -- to store the unencrypted data anyway.

Re:"Despite Using SSL" (4, Interesting)

icebike (68054) | about 10 months ago | (#44058207)

That has never been the standard. And it would have violated several standards if you arbitrarily decided to not cache any ssl delivered data. Ssl was for protection of data in transit, not before or after the transmission is complete. The protection was not intended to outlive the actual connection.

You are confusing the recommendations for caching proxies with the recommendation for the intended endpoint.

Re:"Despite Using SSL" (0)

Anonymous Coward | about 10 months ago | (#44058757)

I didn't claim it was required by the standard. But it would not violate standards if you decided not to cache SSL delivered data. The standards don't *require* you to cache anything.

Shift-reload every time you switch away (2)

tepples (727027) | about 10 months ago | (#44059147)

The standards don't *require* you to cache anything.

But if web browsers were to routinely do the equivalent of a Shift+reload every time the user switches away from and back to a browser tab because there is no cache, web server operators would likely be up in arms over bandwidth "abuse". They'd end up putting in a module to provide an intentionally low-bandwidth experience to users that don't cache, identified by their user agent or by a session cookie.

Re:Shift-reload every time you switch away (2)

jeffmeden (135043) | about 10 months ago | (#44059613)

The standards don't *require* you to cache anything.

But if web browsers were to routinely do the equivalent of a Shift+reload every time the user switches away from and back to a browser tab because there is no cache, web server operators would likely be up in arms over bandwidth "abuse". They'd end up putting in a module to provide an intentionally low-bandwidth experience to users that don't cache, identified by their user agent or by a session cookie.

Ding ding ding! What has happened is the unintended consequence of sites using SSL as a blanket instead of a pinpoint. It used to be that the burden of encryption was only placed on the most sensitive of data, like a banking session or a protected site log-in, so caching it was de facto a bad idea since the user isnt likely to visit those specific pages often, and is never likely to want to see what was there the last time they visited. Now, with CPU cycles so cheap that we might as well encrypt everything (and with more users wanting to see "https://" everywhere they go), using SSL as a signal of pages unworthy of caching is not practical. What should have been done "the right way" in the web sites AND browsers of yore was ignored due to the browsers preferring a non-universal way of handling cache, relieving web sites of the need, and has been undone by websites that dont have the need (encrypting your google searches? come on, they are spying on you anyway) leaving us all in the uncomfortable position of realizing that what was a good idea YEARS ago is still not followed very closely.

HTTPS to avoid session cookie cloning (3, Informative)

tepples (727027) | about 10 months ago | (#44059943)

It used to be that the burden of encryption was only placed on the most sensitive of data, like a banking session or a protected site log-in [but there are] websites that dont have the need (encrypting your google searches? come on, they are spying on you anyway)

If you allow users to log in at all but don't encrypt everything, an attacker who can see a user's packets can snoop the user's session cookie and issue requests as that user for several minutes to several hours. The "Firesheep" plug-in, which allowed cloning the Facebook sessions of other users connected to the same wireless network, was the first widely reported incident of this.

Re:"Despite Using SSL" (2)

blueg3 (192743) | about 10 months ago | (#44059243)

And it would have violated several standards if you arbitrarily decided to not cache any SSL delivered data.

What part of the standard? Last I knew, you're not required to cache any data, and what data you choose to cache and not cache is up to you, unless the headers tell you otherwise.

Re:"Despite Using SSL" (1)

operagost (62405) | about 10 months ago | (#44060921)

It's not arbitrary if a browser has an option to not cache any data received over SSL. Using SSL implies some or all of the information is sensitive-- it's just a tool to help the browser and the end user decide when to not use cache without reducing performance the rest of the time. I would like that feature, since we can't trust the site to protect this information.

Simple (2)

c0lo (1497653) | about 10 months ago | (#44058071)

Make all you sensitive transaction from a live read-only image of the OS.

...

My apologies: I forgot that, in this imperfect world, there are hardware/OS-es which can't be booted from a live image.
(ducks)

Re:Simple (0)

Anonymous Coward | about 10 months ago | (#44058431)

>Make all you sensitive transaction from a live read-only image of the OS.

Overcomplex solution. Use a crypted partition/LVM volume/whatever to store your personal data: this will also helps if your computer is stolen.

Re:Simple (1)

OolimPhon (1120895) | about 10 months ago | (#44058595)

Overcomplex solution. Use a crypted partition/LVM volume/whatever to store your personal data: this will also helps if your computer is stolen.

Overcomplex solution. This is cache data; not data you wish to keep for its own sake. Just set your browser to keep its cache in /tmp and it will be cleared at every boot.

Re:Simple (1)

Lennie (16154) | about 10 months ago | (#44058869)

Overcomplex solution for this specific problem (you might have other reasons)

As the article states, if you don't want anything cached Use Private Window/Incognito mode.

Or Safari, Safari doesn't cache at all for HTTPS.

Bandwidth bill (2)

tepples (727027) | about 10 months ago | (#44059155)

Safari doesn't cache at all for HTTPS

Perhaps this is why certain web sites don't support HTTPS at all: because Safari users would run up their bandwidth bill.

Re:Simple (1)

peragrin (659227) | about 10 months ago | (#44058851)

I don't understand why all OS's are read only.

Why haven't we broken the OS down into a read only and configuration/data sections yet? OS's themselves only get updates occasionally. a secure reboot install updates, and reboot again into read only mode.

Now if you do get a virus you reboot, if it manages to stay around in your data you can purge it easier.

Re:Simple (0)

Anonymous Coward | about 10 months ago | (#44059033)

Most system files are only writable by the root user. What is the difference between `read-only' and `only writable by root' in practice?

Re:Simple (1)

jeffmeden (135043) | about 10 months ago | (#44059639)

Most system files are only writable by the root user. What is the difference between `read-only' and `only writable by root' in practice?

Hm, the practice of "lets put this button in front of the user that they can click to become root!" might be part of it...

Re:Simple (0)

Anonymous Coward | about 10 months ago | (#44061089)

That seems more of a problem with the user of the system, not the O.S. design. Root privileges were not intended to be accessible by normal users.

Reboot every few days (1)

tepples (727027) | about 10 months ago | (#44059193)

OS's themselves only get updates occasionally.

For one thing, "occasionally" has tended to mean every couple days. Unlike Windows security updates, Ubuntu security updates don't wait until the operating system is on its period [wikipedia.org] to correct known defects. For another, some applications get updates on a schedule that doesn't line up with operating system updates. Would you want to have to disconnect from chat channels, pause your streaming music, log out all users, and reboot the system every time one of the many applications on your system gets an update?

Re: Reboot every few days (0)

peragrin (659227) | about 10 months ago | (#44059267)

I said OS not applications. I didn't even mention The GUI layer which could go on either side.

The problem we have is applications require direct hardware access. You have a broken OS when a web browser plugin requires direct hardware access(flash).

Your use of "direct hardware access" confuses me (1)

tepples (727027) | about 10 months ago | (#44059345)

The problem we have is applications require direct hardware access. You have a broken OS when a web browser plugin requires direct hardware access(flash).

What sort of kernel-level "direct hardware access" does Flash Player perform? I wasn't aware that Flash Player was making disk writes at the sector level (not the file level) or writing to individual I/O ports or anything. What sort of indirect hardware access would you recommend instead?

Re:Reboot every few days (1)

operagost (62405) | about 10 months ago | (#44060979)

Unlike Windows security updates, Ubuntu security updates don't wait until the operating system is on its period to correct known defects.

From the article to which you linked.

Sometimes there is an extraordinary Patch Tuesday, 14 days after the regular Patch Tuesday.

Re:Simple (0)

Anonymous Coward | about 10 months ago | (#44059565)

Because those configuration sections have such a huge footprint that they are, effectively, just as insecure as having writable access to the binaries. If you look at security vulnerabilities, most of them don't care much about writable OS executables.

Re:Simple (1)

X0563511 (793323) | about 10 months ago | (#44060779)

If anything, the binaries are the lesser risk - binaries can be signed, signing configuration is not so easy.

Re:Simple (0)

Anonymous Coward | about 10 months ago | (#44061241)

Or just use incognito mode/private browsing.

Safari doesn't cache at all (4, Informative)

david.emery (127135) | about 10 months ago | (#44058091)

From the securityevaluators.com document (2nd reference in the base article): Safari. Apple Safari does not cache HTTPS-delivered content to disk, regardless of any headers sent by the server. ISE tested the mobile version of Safari on an iPad 2, and the HTTPS caching behavior was identical to the desktop version.

This is actually a very bad idea, if true (2, Interesting)

YA_Python_dev (885173) | about 10 months ago | (#44058169)

This actually decreases security. Browser caching is strictly necessary to make the web work fast, disabling it for HTTPS means discouraging websites from using secure connections for anything where it's not strictly necessary (like money). And $DEITY knows we live in a world where every website should be secure by default. You wouldn't use telnet even for a completely non-sensitive server, so why accept unencrypted HTTP to post on slashdot or anywhere else?

Re:This is actually a very bad idea, if true (3, Insightful)

bloodhawk (813939) | about 10 months ago | (#44058543)

The real problem here is the standard is just plain retarded. Even though I hate Apple I think their approach is the lesser evil. The default should be don't cache, web servers should then be able to enable caching if they want to sacrifice some security for performance (assuming the user hasn't explicitly disabled caching). It would be nice to be able to rely on users having well managed machines or the internet being made up of mostly well managed servers but lets face it that aint happening anytime soon in anything but well run enterprises and IT literate end users.

Re:This is actually a very bad idea, if true (1)

X0563511 (793323) | about 10 months ago | (#44060833)

It would be interesting if caching could be defined per element - so you could cache everything on a page except for the sensitive elements (without relying on framesets or other kludgery)

Re:This is actually a very bad idea, if true (4, Insightful)

anegg (1390659) | about 10 months ago | (#44059149)

Note that the claim is that Safari doesn't cache to DISK, not that Safari doesn't cache. I.e., Safara doesn't store information that was deemed sensitive enough to require a secure channel on a long-term (probably unencrypted) storage medium.

Scaremongering (1, Insightful)

YA_Python_dev (885173) | about 10 months ago | (#44058093)

This is BS. If an attacker has access to your files in your local disk, they have already won.

Re:Scaremongering (1)

Anonymous Coward | about 10 months ago | (#44058123)

If someone's using a shared computer, or if they let someone else use their computer, they might reasonably expect their banking information to be inaccessible after they've logged out of the bank's website.

If it turns out that information is accessible when people don't expect it to be, that's a real security problem, and neither "scaremongering" nor "BS".

Re:Scaremongering (2)

YA_Python_dev (885173) | about 10 months ago | (#44058147)

A shared computer should not let users see other users' private files (and browser caches are most definitely not world-readable). This is what happens with Android multi-login, Chrome OS and traditional Linux distros. I'm fairly certain the same is also true for Windows and Mac OS X.

If I temporarily let someone use my computer with my account, I sure as hell keep an eye on what they are doing, because the thing contains stuff about me that's much more sensitive than anything that paypal or my bank will ever know.

Re:Scaremongering (1)

Anonymous Coward | about 10 months ago | (#44058571)

You are thinking about a multi user system, where each person has his own login.

That's not the case if you use a shared computer e.g. at the library.

Re:Scaremongering (0)

Anonymous Coward | about 10 months ago | (#44058579)

If you do banking on a shared computer, then you deserve what you get coming at you.

Re:Scaremongering (1)

Anonymous Coward | about 10 months ago | (#44058705)

Not everyone can afford their own computer and internet access. Public libraries are still a very valued asset by many people.

Re:Scaremongering (1)

CastrTroy (595695) | about 10 months ago | (#44058903)

Perhaps people can't afford not to have their own computer if they risk having their personal information taken when using the library computers. Of course, it's worth noting that libraries, at least the one's I've been to, actually do a pretty good job of wiping the data between sessions. At the very least, if your library doesn't do this, they should have Chrome/Firefox installed so that you can browse in Incognito/Private mode.

Bring your own device (1)

tepples (727027) | about 10 months ago | (#44059213)

You don't need your own Internet access. You can buy a $200 Nexus 7 tablet and carry it into the public library.

Re:Bring your own device (1)

halltk1983 (855209) | about 10 months ago | (#44060015)

You can buy a lot of ramen, rice and pasta with $200. That's a big ol' chunk of change for someone that's truly broke.

Re:Scaremongering (2)

jkflying (2190798) | about 10 months ago | (#44058153)

If you're not using your computer, you should expect keyloggers and never sign into anything which doesn't have 2-factor authentication.

Re:Scaremongering (0)

Anonymous Coward | about 10 months ago | (#44058205)

The point of the story is that even when you -do- have 2 factor authentication, the browser cache may expose some private data after you've logged off and left.

Re:Scaremongering (0)

Anonymous Coward | about 10 months ago | (#44058487)

If the machine is not yours and in your control you should not be doing anything with critical data on it. There should be no concern about after you leave as only you have access to the data in the cache, if you are some sort of retard doing private transactions on a shared computer where their is no profile/home folder data security there you deserve everything that happens to you.

Re:Scaremongering (1)

Anonymous Coward | about 10 months ago | (#44058167)

Not true. Just because the attacker has full access to an incorrectly configured /tmp directory (or equivalent) doesn't mean they have full access to everything you do.

Re:Scaremongering (1, Interesting)

Mashiki (184564) | about 10 months ago | (#44058177)

Well considering the general quality of networks, improperly secured routers, and secondary infection points via home networks and 'open disk' access that things like Windows love to do when you use that lovely auto-config tool. Chances of leaving a wide-open door, and letting them win are pretty good.

Re:Scaremongering (1)

Charliemopps (1157495) | about 10 months ago | (#44059019)

The point is, if all this data is cached to disc, if you hardware is EVER compromised... now or in the future... they have it. If it weren't cached, then they'd have to attempt to circumvent the banks security system. I think the most likely scenario here is your laptop gets stolen, the thieves search for images and find all kinds of pictures of old checks in your cache folder.

AES cache (2)

tepples (727027) | about 10 months ago | (#44059231)

if all this data is cached to disc, if you hardware is EVER compromised... now or in the future... they have it

Then encrypt the cache with a secret key that changes every time the browser is restarted. A key won't last very long in a powered down system unless the attacker does the highly visible operation of physically freezing the RAM.

Re:Scaremongering (1)

blueg3 (192743) | about 10 months ago | (#44059283)

That is BS. There are plenty of scenarios in which an attacker having read access to your browser cache is significantly less privileged than the sensitivity of information discussed here.

donald duck likes to fuck (-1)

Anonymous Coward | about 10 months ago | (#44058141)

it's his sweet semen which holds his house together!

not looking hard enough (1)

dutchwhizzman (817898) | about 10 months ago | (#44058175)

There are plenty more financial sites than 21 that do that. They must not have looked very hard or at a lot of sites.

Hmmm (1)

wbr1 (2538558) | about 10 months ago | (#44058279)

Never...trust...apps..or..websites..to...store...data..safely...

This is my first rule. The solution.. whole drive encryption. The tinfoil hat of secondary storage.

Re: Hmmm (0)

Anonymous Coward | about 10 months ago | (#44058537)

Oh dude, face palm fail. First rule of securely storing data is don't talk about securely storing data.

Re:Hmmm (1)

blueg3 (192743) | about 10 months ago | (#44059299)

That protects you against someone stealing your hard drive -- which is a pretty reasonable fear if you have a laptop. It does nothing against malware, which is enormously more common.

So what? (0)

Anonymous Coward | about 10 months ago | (#44058321)

The data is on your own machine. If your disk is encrypted, the data is safe at rest. When the machine is running, don't allow random people access to your machine.

Re:So what? (1)

tepples (727027) | about 10 months ago | (#44059241)

Not everybody has the money to be handing out Nexus 7 tablets like candy to house guests and telling them "use this instead of my computer".

Interesting second link (4, Interesting)

Bearhouse (1034238) | about 10 months ago | (#44058329)

With a well-written and refreshingly non-partisan review of why and how this happened, showing that, as with many cluster-fsuks, it's the result of a chain of decisions where each seemed sensible at the time.

Everybody dropped the ball here:
- website owners & authors too incompetent or lazy to keep abreast of standards and changing conditions,
- Microsoft for being, well, Microsoft (not really respecting standards),
- Google (Chrome) & Mozilla for changing the default behaviour of their browsers to store https traffic instead of not, (although this, ironically, is the standard unless the site properly says "do not store"; see point 1.)

Raises the interesting question; who on earth thought, in this era of increasing bandwidth, that it would be a good idea to store https data locally?

Re:Interesting second link (2)

anegg (1390659) | about 10 months ago | (#44059211)

Part of the problem is that the browser, which should be a tool of the user, has become a surrogate tool of the servers which the user accesses. The more that browsers are called upon to do to offload processing from the server (Java, Javascript, etc.) the less the browser is under the control of the user. For example, reading any major news site, the "other things you may be interested in" links all appear in Explorer and Safari to be simple links, but they actually have complex Javascript that routes your click through "outbrain" for analytic processing... you can turn off Javascript to avoid this, but then many other sites you use will stop working.

Cap (1)

tepples (727027) | about 10 months ago | (#44059253)

in this era of increasing bandwidth

What "era of increasing bandwidth"? ISPs have tended to switch home Internet plans from uncapped to capped. Satellite and cellular, for example, usually have a cap of 10 GB/mo or less.

Re:Interesting second link (0)

Anonymous Coward | about 10 months ago | (#44061387)

I want my https data cached locally, that massively speed things up. What I don't want is that data to persist after I close the https tab.

Long story (1)

Anonymous Coward | about 10 months ago | (#44058347)

I recall many years ago spending almost an entire day trying to really understand what is up with the caching headers. There is what you read in the RFCs and there is reality.

The early dialup days brought with it some creative tweaking of meaning of headers during the great IE/mozilla wars in persuit of the fastest browser in all the world...Insanity propogated by caching proxy vendors thrown into the mix lead to none of this shit actually working the way it was supposed to.

No-store wins but to this day I have no idea what header I need to send to prevent IE from caching an XMLHTTPRequest. I don't think its possible.

If you really want to go after financial sites for security there is no shortage of low hanging fruit such as absence of the secure header when sending cookies to the browser.

Cookies are not the pb (0)

Anonymous Coward | about 10 months ago | (#44058527)

Everytime you give programmers tools you should expect they will be twisted in every possible way.
So Bad designs, lazy or even awful programmers work on every companies even the sensitive once. My guess is that you could find such mistakes on almost every website or app where security wasn't on the roadmap.

I worked for banks and even if they do the same job security is no always priority.
- Bank One as their "basic" security scan open every TCP request on your server to watch if there is no sensitive informations that could be intercepted. If you do an SQL query on sensitive information they have automatic alerts and people come to the room you are in less than 5 minutes.
- Bank Two have almost nothing and some sensitive database still have the default account and password usable. Or some sensitive database are duplicated on non secure datamart.

Disk cache (1)

jones_supa (887896) | about 10 months ago | (#44058549)

Simple: a web browser should not save any content from encrypted sources.

Additionally: why do we even have browser disk cache in place anymore? Most of the pages of modern web are dynamic (cgi-bin), so you never want old copies anyway.

Re:Disk cache (0)

Anonymous Coward | about 10 months ago | (#44058573)

What kind of helps is a VM or a sandbox, simply set up a clean browser setup, without connecting it to the internet, customize everything to your demands, e.g. no cookies, java off, frames off, redirections off, additional "config" settings, etc., then open it in a VM/sandbox, connect it to the net, browse sites, and when you're done, remove the sandbox/"null" the vm.. done. Almost no traces within your base system.

Re:Disk cache (1)

blueg3 (192743) | about 10 months ago | (#44059313)

Additionally: why do we even have browser disk cache in place anymore? Most of the pages of modern web are dynamic (cgi-bin), so you never want old copies anyway.

Web servers tell the browser not to cache dynamic pages. (So, for dynamic pages, it's like there is no disk cache!) But the bulk of the data is in static resources used by those dynamic pages, like images and Javascript libraries.

Re:Disk cache (0)

Anonymous Coward | about 10 months ago | (#44059493)

Additionally: why do we even have browser disk cache in place anymore? Most of the pages of modern web are dynamic (cgi-bin), so you never want old copies anyway.

Web servers tell the browser not to cache dynamic pages. (So, for dynamic pages, it's like there is no disk cache!) But the bulk of the data is in static resources used by those dynamic pages, like images and Javascript libraries.

Is it possible for browsers to cache the encrypted data, prior to SSL decoding. Subsequent request for the same image etc. the browser can read the encrypted form from the local cache instead requesting the same from the server. is

Perhaps the SSL symmetric key could be used to encrypt the cache data, to ensure that the key is transient.

I don't get it (0)

Anonymous Coward | about 10 months ago | (#44058551)

Temp files aren't supposed to be publicly visible anyway. If you want private browsing, browsers have a special mode for that. Otherwise the browser caches what it can, which is a good thing. SSL is about preventing online eavesdropping, it has nothing to do with whether the browser stores data on your hard drive. Protecting the data on your hard drive is up to you.

Re:I don't get it (0)

Anonymous Coward | about 10 months ago | (#44058721)

If the browser does not encrypt the cache and you can't redirect that data to some encrypted file, which only that browser can access, then it is not up to user, because every other program could then access that cache. Also the browser needs to make sure only that site, where the data came from, can access the data. If other sites can access everything in cache, then the whole SSL thing is useless.

outsourced to lowest bidder (0)

Anonymous Coward | about 10 months ago | (#44058965)

How many of these mega-corporation web sites were outsourced to the lowest bidder? You get what you pay for.

This is why I still use IE from time to time (1)

RevWaldo (1186281) | about 10 months ago | (#44059045)

Not because it's better, heaven's no. It's because most financial and government institutions use it as the web standard they develop toward, since it's the standard browser in the office. Note I'm talking about institutions not generally internet-oriented, like the bank or the water company.

.

Confirms what I've suspected ... (3, Interesting)

gstoddart (321705) | about 10 months ago | (#44059189)

This pretty much confirms what we've all known for a long time -- the security of these things is largely written by people who are unqualified to write secure applications, and people who write IE specific stuff write shit code.

Your financial information is being handled by people who are either lazy or incompetent, and the company is more interested in the spinning, flaming logo than anything like security.

It would be a mistake ... (1)

Rambo Tribble (1273454) | about 10 months ago | (#44060839)

... to think that financial institutions are very serious about security. Their losses are covered by the consumer, so getting their hands on the consumer's money takes a much higher priority than protecting it. Of course, they justify it as "convenience" for the consumer, but it really all about the convenience for them.

Firefox fix (1)

wiredlogic (135348) | about 10 months ago | (#44061367)

With Firefox you can make the cache stay in RAM with the following about:config settings:

browser.cache.memory.enable =True
browser.cache.disk.enable = False
browser.cache.memory.capacity = 512000 (or whatever you prefer)

The alternative for all browsers is to put the disk cache on a RAM drive.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...