Forgot your password?
typodupeerror
Encryption Businesses Government Security

Calif. Attorney General: We Need To Crack Down On Companies That Don't Encrypt 127

Posted by Soulskill
from the making-it-more-painful-to-be-bad-at-security dept.
tsamsoniw writes "California Attorney Kamala Harris says her office will start cracking down on companies in the Golden State that don't encrypt customer data and fall victim to data breaches; she's also calling on the state to pass a law requiring companies to use encryption. That's just one of the recommendations in the state's newly released data breach report, which says 131 companies in California suffered data breaches in 2012, affecting 2.5 million residents."
This discussion has been archived. No new comments can be posted.

Calif. Attorney General: We Need To Crack Down On Companies That Don't Encrypt

Comments Filter:
  • NSA (Score:4, Funny)

    by Anonymous Coward on Wednesday July 03, 2013 @05:26AM (#44174085)

    We Need To Crack Down On Companies That Do Encrypt

    • by Anonymous Coward

      It is a shame that even popular open source projects dont bother. For example Mozillas Thunderbird chat has no OTR support, Mozilla Firefox and other browsers treats self encrypted certs as WORSE than unencrypted and put big scary messages up. Instead there really should be three different "modes" - what exists now in all browsers for the certificate authorities for those who want to talk to their banks etc, self signed certs which should just work like an unencrypted link (no full secure icon etc), then pl

      • Re:NSA (Score:5, Insightful)

        by Chrisq (894406) on Wednesday July 03, 2013 @06:59AM (#44174409)

        Mozilla Firefox and other browsers treats self encrypted certs as WORSE than unencrypted and put big scary messages up

        I think it is reasonable action for a certificate you don't know the source. You can always add the certificate to your browser [mozilla.org] and avoid the error. The rationale for the pop-up is that an unknown self-signed certificate is as bad as no encryption - totally open to a main-in-the-middle attack, but people have a higher expectation of security from SSL.

        • Re:NSA (Score:5, Insightful)

          by tajribah (523654) on Wednesday July 03, 2013 @07:24AM (#44174521) Homepage

          Is "as bad as no encryption" a reason for yelling on the user and presenting it like the worst security problem ever? Even if I accept the premise that it is as bad as no encryption, the obvious conclusion is that the browser should present it the same as no encryption.

          Actually, it is not as bad. It still keeps you safe from passive attacks (like your ISP collecting all data for a three-letter agency, which analyses them later).

          • by rioki (1328185)

            Well it depends on what you are doing. Using your own private service over the internet secured by SSL, no big deal, register the cert. Using your online banking and the cert is self signed, better check on that. The reason is that no encryption is clear that it is unsafe and most people will (hopefully) not do anything sensitive. But putting trust in a self signed certificate is a gamble, especially when you assume that this SSL connection is being used to transfer secure data. The reason why it is conside

            • That is an "all or none" argument. If self signed certs look feel and behave the same as what unencrypted does now, then people have no reason to behave differently than they do with unencrypted. Sadly and as numerous researchers have shown (like this one - "Crying Wolf: An Empirical Study of SSL Warning Effectiveness" [psu.edu]) people quite happily transfer secure data over unencrypted connections in the current setup anyway. This further undermines your argument and the rational that treating self signed certs
          • by AmiMoJo (196126) *

            It isn't the same as no encryption. The site is making a claim that cannot be verified, and which often points to fraud. Treating it as unencrypted would open up all sorts of man-in-the-middle attacks by criminals, ISPs and three-letter agencies quietly intercepting and replacing security certificates. Do you think people check for HTTPS and a valid cert every time they connect to their bank or email account?

            • by tajribah (523654)
              I expect the browser to clearly inform the user whether the connection is safe (HTTPS with a verified certificate) or unsafe (either plain HTTP, or HTTPS with an unknown certificate). I also expect the user to check that a connection to his bank is reported as safe. If you are interested in preventing attacks against careless users, the browser might also notify the user that a site previously known to have a safe connection, no longer has one. However, I do not think this is of much help: many users just
            • No it isnt that same, it is better. Unencrypted is already open all sorts of man-in-the-middle attacks by criminals, ISPs and three-letter agencies are already "quietly intercepting", and recording EVERYONES traffic. Making them go one step further an have to target individuals in order to replace a deluge of self signed security certificates is a big positive step. Also If self signed certs are never blessed with security icon by default then people will not fall for fraudulent fakes - because the brows
          • I think part of the rationale is that a self-signed certificate very well might be a sign that you're the victim of a man-in-the-middle attack, and it needs to be treated as a serious potential threat.

            Personally, I don't think the problem is that web browsers treat self-signed certs as dangerous. I think the real problem is that the only infrastructure we have for authenticating certificates is expensive and unwieldy. We need to have a way of generating and authenticating certificates that's easy enough

            • by tajribah (523654)

              I think part of the rationale is that a self-signed certificate very well might be a sign that you're the victim of a man-in-the-middle attack, and it needs to be treated as a serious potential threat.

              This sounds good in theory, but the reality is that self-signed certificates (or those signed by an authority your browser does not recognize) are several orders of magnitude more common than MiTM attacks.

              Otherwise, I agree that a big part of the problem is unusable UI for managing certificates in almost all existing browsers.

        • Re:NSA (Score:5, Insightful)

          by FriendlyLurker (50431) on Wednesday July 03, 2013 @07:35AM (#44174567)

          people have a higher expectation of security from SSL.

          I think the GPs point was that it does not have to be a all or none - that you can have SSL of a self signed cert without the error message and without giving any "expectation of [high] security" (to quote GP "no full secure icon")

          The rationale for the pop-up is that an unknown self-signed certificate is as bad as no encryption

          In light of the Snowden revelations and subsequent fallout, this rational has very few legs to stand on. Unencrypted is less desirable than plain text. The only argument I have seen against this rational is that people may be lulled into a false sense of security if they believe self signed certs are as secure as CA issued ones, falling for MITM attacks for their bank traffic etc. The counter to that is that is simple and sensible: no, not if the browser does not try to tell them they have a top secure connection - and treats it like it is a plain text connection.

          self-signed certificate is... totally open to a main-in-the-middle attack

          The current SSL system is also totally open to a main-in-the-middle attacks by state sponsors, as has been reported here various times. And yes self signed certs are also very vulnerable to the same attack - but the point here is to encrypt the majority of data. State sponsers can always target but with blanket always on encryption they are unable to perform mass illegal capture and storage.... that is the point of not raising an error message on self signed certs.

          Any way I cut these arguments, browsers appear to be in the wrong on this one - throw in cosy relationships with CAs, state departments etc and we could have a conspiracy here.

          • by blueg3 (192743)

            The current SSL system is also totally open to a main-in-the-middle attacks by state sponsors, as has been reported here various times. And yes self signed certs are also very vulnerable to the same attack - but the point here is to encrypt the majority of data.

            They're not vulnerable to "the same attack". One attack requires hacking a CA or exerting very substantial influence over them. The other doesn't. The set of malicious actors who can -- and do -- MitM you if you use self-signed certs is much, much larger than the set of actors who can do it if you use CA-signed certs.

            The only argument I have seen against this rational is that people may be lulled into a false sense of security if they believe self signed certs are as secure as CA issued ones, falling for MITM attacks for their bank traffic etc. The counter to that is that is simple and sensible: no, not if the browser does not try to tell them they have a top secure connection - and treats it like it is a plain text connection.

            Yes, that's pretty much the argument. The danger is that they could think that their connection is somehow more secure than plaintext. You cannot safely fix this without determining user intent

            • The danger is that they could think that their connection is somehow more secure than plaintext.

              It is a danger *only* if the browser is giving some indication of security. If the browser does not give any indication or expectation of privacy with self signed certs then there is no danger. Most browsers already do not show the protocol being used for plaintext (no http// display).

              You cannot safely fix this without determining user intent, and even the user can't usually be trusted to determine their intent.

              You can safely fix it by not giving any change to normal unencrypted experience. If they intended to use HTTPS to get real security but instead were presented with a self-signed certificate, and the browser defaulted into plai

              • If they intended to use HTTPS to get real security but instead were presented with a self-signed certificate, and the browser defaulted into plain text view (no ssl icon or indication of security) then the user does not need any extra warning.

                When I make a request to a https url I expect the information contained within that request (parts of the url other than the hostname, post data if any, cookies if any) to be sent over an encrypted and authenticated link. By the time I can "look for the padlock" the potentially private information has already been sent. So if the connection cannot be authenticated the browser MUST warn me* BEFORE it continues with the request.

                I support systems that allow encrypted but unauthenticated connections to be prese

                • You are right about https redirects, my mistake thanks for the correction. They are just so common now it appears to be default browser behavior.

                  When I make a request to a https url I expect the information contained within that request (parts of the url other than the hostname, post data if any, cookies if any) to be sent over an encrypted and authenticated link. By the time I can "look for the padlock" the potentially private information has already been sent. So if the connection cannot be authenticated the browser MUST warn me* BEFORE it continues with the request.

                  It sounds to me like invoking a very special, very peculiar and rare case to support the current status quo: That of communication of private data during initial handshake. How can a user be sending private information (credit card info in form post data for example) with an expectation of privacy on their part if they have not even accessed the webpage, ever, yet?

            • OT

              Is there a list of CAs that have been compromised, including evidence. I.E. it would post two signed and valid certificates for google.com for the same time period but one of them with obviously the wrong IP address?

              • Dude... companies do this all the time, if for no other reason than to compress network traffic. They just buy boxes like this one [sourcefire.com]. All you do is override DNS and CA. It's standard practice.

                • Of course... you need to override CA. I do that too using Charles Proxy to inspect HTTPS traffic locally.

                  But the big unsubstantiated thought out there is "governments have backdoors in to CAs". This is very easy to prove with evidence, but with no evidence we should probably assume the null hypothesis.

          • With DNSSEC we should be able to publish and verify certificate information via signed dns records, which would also shift the root of the trust relationship up to the dns registrars. And since the authentication part of CA certificates is tied to dns already, I don't see that this would change much.
          • by FooAtWFU (699187)

            "I think the GPs point was that it does not have to be a all or none - that you can have SSL of a self signed cert without the error message and without giving any "expectation of [high] security" (to quote GP "no full secure icon")"

            Can you, really? I mean, we have a big enough problem with training users to type credentials in a login box served by http://www.myfavoritebank.com/ [myfavoritebank.com] all insecure-like. This area where security intersects user interaction design is a tricksy one.

        • by Bert64 (520050)

          On the other hand, a self signed certificate which you have explicitly accepted is in many cases *BETTER* than a ca verified cert. In the former case you have explicitly chosen to trust a single party, whereas in the latter you are reliant on a large number of organisations.

          • by dkf (304284)

            On the other hand, a self signed certificate which you have explicitly accepted is in many cases *BETTER* than a ca verified cert. In the former case you have explicitly chosen to trust a single party, whereas in the latter you are reliant on a large number of organisations.

            A self-signed certificate is better only if you can independently verify that you've got the correct certificate and that it is still valid. Otherwise it is worse, because you've got no way at all to figure out if it is correct and whether it has not been rescinded yet (e.g., because of a break-in on the server). You're far better off to have a private CA run by someone you trust and to explicitly only trust that CA to issue for a particular service, rather than some random other CA. (The downside? That doe

      • by Darinbob (1142669)

        True. If a corporate cert goes out of date then the warnings pop up and it's a bit confusing at times to figure out how to proceed. Ie, the choice in Firefox between "I know what I'm doing" and "get me out of here" certainly doesn't instill confidence when trying to add the cert.

  • wait (Score:5, Funny)

    by Yaur (1069446) on Wednesday July 03, 2013 @05:26AM (#44174087)
    We have reached the point in time where attorneys general have realized that companies need to encrypt customer data? Either that happened faster than I expected or I'm getting old faster than I realized.
    • May well be down to shareholder pressure and I expect shareholders would not wish to have company IP or indeed customer data outside of their control. What is good for shareholders is good for business and good for votes needed by those in public office.
      • by gstoddart (321705)

        What is good for shareholders is good for business and good for votes needed by those in public office.

        Well, what was 'good' for shareholders was getting a product out the door, and not spending all of that money on implementing any actual security.

        If there's no penalty for not having good security and/or encryption, why would a company spend money on it? From that perspective, it would be bad for shareholders and business.

        If you make it costly to have data breaches, it becomes good for shareholders to imp

    • by AmiMoJo (196126) *

      Does she also realize that ROT13 isn't sufficient "encryption" though?

      HMRC (UK tax office) lost a CD with 15 million people's personal data on it. They released a statement saying it was password protected. A password protected MS Office document is not really "protected" in any meaningful sense.

      • by mlts (1038732) *

        Depends on what version of Office/Word. A document secured with a 32+ character password in a recent version (Office 2003 and newer) can use SHA 512 and AES-CBC.

        Of course, using a weak password, all bets are off.

        If one needed to distribute data on CD encrypted the "right" way, I'd either use a large PGP archive, ship the CD with a TC volume and a keyfile encrypted to the receiving site public keys, or use a commercial utility like PGP Disk and have a volume only openable with the receiving site keys.

        Done r

  • encrypted or the credit card companies won't do business with you. (PCI compliant or something like that)

    That leaves social security number and email address/password, but really, you should not use the same password for your Gmail account and Oily Pete's V1agra Online. As for social security, never give it out to anyone under any circumstances unless it's a bank (real one, not a Nigerian prince bank) and you're asking for a loan or opening a checking account.

    Just drill that into the head of the IQ challeng

    • by MrDoh! (71235)
      I thought everyone had to be already. Least all the hoops I've had to jump through with all our clients who insist in it, and auditing of it.
    • by blueg3 (192743)

      Since when is credit card data, e-mail address, and password the only "customer data" a company keeps about you?

    • by Bert64 (520050)

      They require that you "encrypt" the data, but they also typically require that you send the data unencrypted (albeit tunnelled over ssl) to actually process a payment, so while the data may be encrypted on disk the server typically also has the ability to decrypt it on demand in order to make use of it... So it's just a case of a hacker working out how, and then triggering the same process to extract the data.

    • by sjames (1099)

      PCI isn't what it's cracked up to be. It looks like yet another scheme to 'do something' about 'the problem'.

  • by Anonymous Coward

    Server side encryption in could is no good. It prevents Calvin reading Susy's diary, but nothing much more than that.

    And no proprietary closed up systems, but publicly verifiable implementations end to end, or it's not even worth trying to get people trust on it.

    • While I agree with your points, I think the public is unfortunately pitifully trusting. This whole NSA spying stuff will pass through the news cycle and soon not be covered again. It's only making a big splash because Fox News likes making fun of the Obama administration, but before the public actually starts demanding their right to privacy, Fox News will bury the issue and convince their watchers that the government is not spying on them. All of the systems we have in common usage are total crap, and a

  • Usually at some point the server needs to be able decrypt the data so it can be displayed to a user, so the key needs to be handy. So if you have the key and data on the same sever it's of little security value.

    If you want to have this data in some kind of database, there is a good chance you want to be able to search and index this data. Possible to index and pre-sort encrypted data without giving away the content?

    Yes, maybe encrypt some sensitive parts, but encrypting all customer data is counter

    • by oPless (63249)

      I detect someone doesnt know what a HSM nor what one is used for.

      Here, have a wikipedia link and learn something today http://en.wikipedia.org/wiki/Hardware_security_module [wikipedia.org] [wikipedia.org]

      • by blueg3 (192743)

        So... explain how that helps when someone hacks into the server and requests data using the same mechanisms and level of authority as the server software (which must ultimately manipulate unencrypted data).

        Because that's what happens.

      • by sjames (1099)

        I detect someone who has no idea what the actual problem is but he has a hammer and the world looks like a nail.

  • Encrypt everything (Score:3, Interesting)

    by Anonymous Coward on Wednesday July 03, 2013 @06:05AM (#44174211)

    Don't just encrypt private details.

    Get rid of users private data, so there is nothing to steal in the first place.

    Use eccentric authentication*. Replaces passwords with anonymous client certificates.

    Check my: http://eccentric-authentication.org/ [eccentric-...cation.org]

  • Create new column types called varhcar2rot13 where the data is inserted it gets a ROT13 encryption applied when read out it automaticly decrypts it.
    Sell to California companies for major money.
  • by Anonymous Coward

    We need to crack down on government agencies that spy.

  • by Anonymous Coward

    ...and in other news, CA police will be cracking down on people who don't lock their house doors and who don't lock their car doors.

  • Using encryption is easy. Managing the encryption keys however, not so much. The number of developers I see posting questions (to StackOverflow) on encryption with NO IDEA on basic key management is very worrying.

    • Make key management automatic.

      Users can't do it wrong anymore. Play with the demo at: http://eccentric-authentication.org/blog/2013/06/07/run-it-yourself.html [eccentric-...cation.org] or take a look at the walkthrough.

      • That has nothing to do with the problem. We are already assuming that the companies have personal data, they just want to encrypt it to prevent third parties from obtaining it. The problem is that you need to decrypt the data at some point in order to make use of it, so the key must sometimes intersect with the data. Where do you keep it so that someone who gets the data won't also get the key?
  • She seems to make a good point, and according to The Wiki she's pretty hot. I feel bad for her significant other (assuming she has one), I bet she's totally nuts.

    • The crazy is in thinking she can regulate better security onto any random industry. It doesn't work like that. Security is too complicated to magically fix by insisting on blind usage of a particular tool.

      If you look at the article, a huge number of the breaches are to do with credit card leaks. Well, duh, credit cards are a pull model not a push model. Bitcoin is more sensible, but the California DFI is busy harassing Bitcoin companies. So if she really cares about upgraded security, maybe she should get t

      • by Stan92057 (737634)
        Bitcoins are a dead issue they will never be a replacement for any kinda legal tender just for the fact its untraceable the government will not allow it. And SOMETHING must be done because they will not do it without being forced to do it."Data centers not encrypting the data they have" Your kind will always find reasons to not do something because well its hard to do right. With your kinda thinking we would have never gone to the moon. And your kinda thinking is keeping us from going to mars not because of
  • by WaffleMonster (969671) on Wednesday July 03, 2013 @08:51AM (#44175113)

    Good laws of this sort are those which do not impose technical solutions but rather provide general systems level requirements.

    The problem with "duh use encryption" there is no guarantee of any kind simply applying encryption makes a system more secure against a specific threat.

    Every time you get into the weeds you are guaranteed to codify errors and hurt those who choose to innovate using different but better or equally valid approaches.

  • by onyxruby (118189) <onyxruby@NOspam.comcast.net> on Wednesday July 03, 2013 @09:26AM (#44175487)

    I've dealt with cleaning up some nasty data breaches over the years, I've had conversations with Attorney Generals when the breaches were bad enough. Companies fear Attorney Generals about as much as they fear being on the wrong end of the international news.

    I've been involved with companies where data breaches happen where Attorney Generals while and while not get involved. The difference is night and day for things like encryption, notification of consumers, risk mitigation and other such steps. Pause and think about it for a moment, do you really think California is breached that much more often than other locations, or do people simply find out because the companies fear being on the wrong end of the Attorney Generals pointy stick?

    Attorney Generals that give a damn are good things, they give the security professionals at the companies in their states the leverage they need to actually do the things that they want to do (encryption etc).

  • Tradition normally holds that a person who does a bad act is the guilty party. These days that is becoming rather twisted. If a person steals data then doesn't the guilt fall upon the thief? What they are doing is similar to the rather absurd gun law that can find a person negligent for simply using one lock to secure a gun. A home owner locks his windows and doors and drives off to the market. Mr. bad guy breaks in the back door and steals the gun and later that day shoots someone. Out of the

  • We need to make companies liable for any information they are so careless as to lose. Intruding on their business process is the wrong way to go about it: punitive liability judgements (and tighter disclosure laws) are the right way.

    Part of the problem here is this horribly mistaken meme that everyone and everything is hackable. It makes people feel not responsible, and it's only true in the sense that evert newborn baby has started dying, or that the universe will cool/stop. Not concerned with this meme

    • by Skapare (16644)

      For things like the electric grid, there shouldn't even be any access at all. It's that critical. It is critical enough that they should have private FIBER following every power line.

      For people info like SSN and bank account numbers, the system should be revised so that the number alone only serves to IDENTIFY and is not treated as AUTHORIZATION. Lots of people have other people's SSNs for various reasons. Using the identification number for authorization is totally wrong. This also goes for credit car

  • ... are essential to the servers that handle the data. They can't actually operate on the encrypted data. They have to UN-encrypted it first (and RE-encrypted it to put it back if there any changes). So what does this mean to me? It means I have to grab the encryption key(s) when I break in to get the data.

    This reminds me of an incident with a state web site. Someone broke in and did some defacing. The state's top IT director answered a reporter's query with "This needs to be investigated because we b

  • .... nothing to the NSA

  • How many mails have you received that were official and digitally signed (not a signature)?
    I work in a company where people are pretty security savy, but email somehow is an exception.. When I ask how they know the mail came from John Doe, they tell it is sure because the email address is John.Doe@example.com.
    When I ask them how person X knows that it came from our company, the answer is "Because the email address is info@example.com.". So while IT enjoys themselves to add useless disclaimers (I AM the int

    • by psydeshow (154300)

      How many mails have you received that were official and digitally signed (not a signature)?
      I work in a company where people are pretty security savy, but email somehow is an exception.. When I ask how they know the mail came from John Doe, they tell it is sure because the email address is John.Doe@example.com.

      Quickest way around that: send out a few emails as the company CEO, and set the Reply-to address to a random colleague.

      Loads of fun, and all you need is a command line on a server somewhere.

      Don't blame me if you lose your job, blame RFC 822...

  • This is way, way, way overdue. Due diligence is what it is. And not encrypting sensitive data is not due diligence.

"Indecision is the basis of flexibility" -- button at a Science Fiction convention.

Working...