I start a big trip in the morning. And that involves my credit card -- at least so I hope. With the new internet SSL issue, that does not put any extra risk on point of purchase transactions, or does it? I tried to ask a couple of clerks at stores today, but got blank stares. Don't all POP's take place over phone lines, so no problem with SSL/Heartbleed?
Several of the restaurants I frequent use swipe machines that communicate to the bank via the internet. Most banks use Triple DES internally, rather than just SSL. Triple DES - Wikipedia, the free encyclopedia Transport Layer Security - Wikipedia, the free encyclopedia
Banks insure depositors for 250,000$ per account, federally (used to be 100,000$) Great, till the till is empty. Internet linked bank accounts aren't insured for a dime, somebody cleans your internet account, to bad, money's gone "in less than 60 seconds" and there's no help from any federally insured deposits shenanigan gizmo, just sayin
First off, I do not have hard evidence. I prefer to use my own tools to document a vulnerability, to capture it in field. Worse, the ones who know are playing a game of Fear, Uncertainty, and Doubt. But one credible source has suggested what may be going on. It appears there are "keep alive" packets that are used in a network connection to make sure it is still up. Usually, very small, their only purpose is to provide a 'time-out' if a link fails. It sounds as if someone screwed up and what should have been a small, keep-alive packet can carry a larger block that could include, unencrypted, plain-text data. This is where the speculation about what it might be in the oversized packets comes in. Now if I were interested, I would use a packet capture utility like wire shark or tcpdump to capture traffic and look for the 'keep alive' packets. But truth be told, I'm leaning towards FUD than FACT. Bob Wilson
‘Heartbleed’ Bug Exposes Passwords, Web Site Encryption Keys — Krebs on Security points to Heartbleed Bug. The Heartbleed Bug, explained - Vox has a high-level overview.
There is no risk from credit card transactions because of heartbleed: For chip cards: - The operating system on your credit card offers only a limited number of operations and all of them preserve the secret data on the card. - More specifically. Your credit card does not use Open SSL (The only affected SSL implementation) and is thus unaffected. - No Point Of Sale terminals that I know of use Open SSL - and even if they did, the information on your credit card can't be spoofed. Some software used in banks for (either for home banking or internal communication) uses Open SSL, but the attack is widely known, servers are being patched and this does not affect your credit card transactions. For cards with magnetic stripes: - Magnetic stripes pose no security at all, but stolen/copied cards are insured and you should not worry more than usual because of beartbleed. BTW. Heartbleed is such a stupid error that the person writing that part of the code should be publicly shamed - and the people who verified it even more so!
Some of the software I manage has the the Heartbeat bug. I was able to find a python script, heartbleed.pl that is open source and clearly shows the fault . . . including a dump of the plain text buffer returned. FYI, some versions of heartbleed.pl are dependent upon other, commercial software. So I'm checking the vendor's support site and once they release their fixes, I'll get copies and test. If it appears to be OK, I'll then implement a staggered upgrade to all of our systems. Bob Wilson
That isn't necessary. I'm sure those responsible likely are beating themselves up more. Besides, it is open source and maintained by volunteers. People doing it out of belief and love of the idea, but not getting paid means the product may not get their full attention. OpenSSL: The Open Source toolkit for SSL/TLS
Who should be shamed are cooperations that use (more like steal) the code without even doing one bit of testing. And get paid for it.
My guess is that ny_rob meant OpenSSL when he said SSL. The bug is only in OpenSSl, which is a free/donateware toolkit. If the site uses some other, likely purchased, toolkit, then there is no problem for Priuschat.
No, not in the big picture. The bad thing about credit cards, is the transaction is only a very small part of the entire chain of data being stored and processed via many servers in many different organizations. You are most likely safe in the initial data transaction simply because it is not worth the effort to capture individual transactions. It is all the bugs not known that one should worry about, not the latest one to make the news. The big payoff is in hacking a companies financial servers where there are many thousand of credit card numbers to sell to criminal organizations. The good thing about credit cards is that you are protected from fraud past the first $50 no matter what method your credit card number was misused if you follow all the notification timelines and requirements.
Verify that the various secure websites you use have patched their OpenSSL and then change your passwords. I notified my trading partners this morning to change their passwords or a change will be forced soon. Hopefully they don't have their passwords hardcoded.
Exernal scans of PriusChat Shop don't reveal that it would be affected by this problem. Priuschat.com does not use SSL (in fact, the certificate is self-signed if you try).
On Good Friday, the vendor plans to release the fixed software. I'll start testing and if it looks good, do the installs over Easter weekend and early next week. Then on Monday, start sharing the list of fixed systems. I'll check with our vendor to see if they advise generating new certs. In theory, the private keys might have been compromised from the buffer overflow. So generating new private/public keys is easy enough and the rest is just 'paper work.' In 'https', if the private key is ever compromised, common tools like Wire Shark can decode the traffic. The certificate carries only the public key and that is freely sharable. But the private key has to be 'in memory' at sometime to decode the encrypted traffic and that is the risk. If the private key is every 'captured' by the bad guys, all traffic can be decoded. Bob Wilson
Huh, well, I don't understand three-quarters of what you guys are talking about, but I take it that I was safe enough using my credit card during my trip to Colorado...
Many credit card companies have a web page that allows you to check for recent activity, bills due, e.t.c. If worried, a few minutes online and the problems are solved. But you reminded me, I need to modify my Amazon/Visa card. I had increased the credit limit planning to buy an airplane engine. But the seller pointed out he is taxed 3% by the credit card company. So I sent him a personal check that should clear next week before I drive up to take delivery: That is a 625cc, 60 hp, 79 lb, liquid-cooled, fuel-injected, oil-injected, electronic ignition, two-stroke, a Hirth 3502. Behind and under the hands holding some of the plumbing is the reduction gear that will swing the in-flight, adjustable, prop at 2350 rpm. Bob Wilson
I went to a Internet Security Seminar the other day offered by my job. One of the best take aways as far as banking online was to use a dedicated pc at home to just do banking. Don't go anywhere else ever on that pc just banking and https: credit card sites. Direct address in URL no google. Banking pc and then an online pc. Really only helps limiting pup's from getting on that banking pc. Cause there's some nasty's out there.I run Malware on that PC freq too. Bought a cheap Dell laptop on eBay for banking. Cost me $50.
