Mint won't give a clear answer about Heartbleed(satisfaction.mint.com)
satisfaction.mint.com
Mint won't give a clear answer about Heartbleed
https://satisfaction.mint.com/mint/topics/a_definitve_answer_on_whether_mint_was_ever_affected_by_heartbleed
https://satisfaction.mint.com/mint/topics/is_mint_com_secured_and_recovered_from_the_heartbleed_bug
12 comments
What is unclear about the response: "As indicated, our engineers have verified Mint is not affected by "Heartbleed." Password resets and re-issuing of SSL certificates are not required at this time."
It seems that they are saying either (a) they are not using OpenSSL, or (b) they were using a version of OpenSSL without the vulnerability. Is there anything wrong with assuming that given their statements?
It seems that they are saying either (a) they are not using OpenSSL, or (b) they were using a version of OpenSSL without the vulnerability. Is there anything wrong with assuming that given their statements?
"is not affected" being the operative wording. users want to know if their data has ever been at risk. still, surely everyone can just assume it was affected, act accordingly, and move on?
Or more likely, they were using software or hardware that was not affected by Heartbleed, and so were not at risk. Saying so would narrow down the infrastructure they are using though, and for a target like Mint, they would likely want to avoid explicitly saying so. Not going to stop a determined hacker, but it may stop the script kiddies with a downloaded toolkit.
After a small amount of research, it looks like they run Java webservers, along with (or on?) F5 Big-IP platforms, with the later likely providing hardware SSL decryption that isn't vulnerable to Heartbleed (mostly, apparently there were some vulnerabilities in certain configurations where it would fall back to Open-SSL.) The way Java webserver allocates memory is also different that the typical Apache/Linux server, so it is unlikely that even if the server was vulnerable that a hacker would actually be able to pull any data of any value from the chunks they could get.
I don't profess to be an expert on server security or the F5 Big-IP platform, but my point is, it would appear that there is no reason to not believe Mint when they say they investigated and have no reason for concern.
After a small amount of research, it looks like they run Java webservers, along with (or on?) F5 Big-IP platforms, with the later likely providing hardware SSL decryption that isn't vulnerable to Heartbleed (mostly, apparently there were some vulnerabilities in certain configurations where it would fall back to Open-SSL.) The way Java webserver allocates memory is also different that the typical Apache/Linux server, so it is unlikely that even if the server was vulnerable that a hacker would actually be able to pull any data of any value from the chunks they could get.
I don't profess to be an expert on server security or the F5 Big-IP platform, but my point is, it would appear that there is no reason to not believe Mint when they say they investigated and have no reason for concern.
Except "is not affected" is exactly what you'd say if you were running software that wasn't, and still isn't vulnerable (because you didn't have to patch anything).
Except in this case, seeing as it seems that Mint hasn't got new ssl certs or private keys, the only way to 'act accordingly' is to never use the service again.
Or they were never vulnerable, which is likely given what has been dug up about their tech stack.
ah, right. i didn't consider that their private key could have been leaked if they were once vulnerable (i was only considering passwords and the like). good point, thanks!
I think there is something wrong with it.
As a site that has access to financial records, I would expect them to explain in detail why they aren't affected and if they were ever vulnerable.
For instance, if they are using IIS (I know, I know) it would be an easy answer.
The fact they are not explaining clearly and in detail leads me to believe that there is/was something amiss.
The transparency expectation of them is greater.
As a site that has access to financial records, I would expect them to explain in detail why they aren't affected and if they were ever vulnerable.
For instance, if they are using IIS (I know, I know) it would be an easy answer.
The fact they are not explaining clearly and in detail leads me to believe that there is/was something amiss.
The transparency expectation of them is greater.
It looks like they are running Java servers on F5 Big-IP platform(s). I tend to believe it when they say they aren't vulnerable, and understand why they would not want to say any more about their architecture than they have to.
Why do they have access to your financial records? Because you gave them the password to your bank account. The consequences of that action were only a matter of time.
True, but people tend to take security in a very strict manner. (With just cause.) The mod could have said, "was not affected", but instead and using improper word use, said "is not affected[sic]". Someone can correct me if I'm wrong, but I believe the proper use is either, was not affected or is not effected, not some combination of the two. The true point is, the statement is inherently unclear as to when, much more so when you introduce faulty word use.
Proper use is to communicate abundant details to remove any ambiguity in phrasing.
Not when you run a service that is a very hot target, in that case, you give as few details as possible to make sure the attack spectrum is as large as possible.
I think their issue is that "is not affected" implies the present moment, and makes no claims about possible exposure in the past.
It's poor customer service, but according to https://github.com/musalbas/heartbleed-masstest/tree/master/..., they were not vulnerable when the first mass scans were done. That's not definitive, but it's at least somewhat reassuring.
netcraft shows mint.com is using f5 BigIP, if they terminate SSL using BigIP and should not be affected: https://devcentral.f5.com/articles/openssl-heartbleed-cve-20...
This needs to be the top comment.
What a bunch of fud.
> You say there's no evidence that customer data was affected, but the heartbleed bug leaves no logs, so that is not re-assuring at all
Well, if they're looking for people making use of the data received by the exploit that is re-assuring..
> You've said before that Mint servers are being updated, which suggests that it was exposed. If this is the case, have you gotten new SSL certificatess? (this is extremely important see next point)
Almost everyone was exposed. I'd like to know they have a new ssl cert too but not because of why you want them to.
> Even if I take a personal precaution and change my Mint and bank account passwords, if a hacker stole your cert at any time and you haven't gotten a new one, all my accounts are STILL vulnerable no matter how many times I change the password. This is because they basically have a permanent back door into Mint until you get a new SSL cert.
No, no they don't I don't think you understand ssl at all.
> Basically, if you don't answer the following questions, we have no choice but to STOP USING MINT FOREVER in order to secure ourselves. 1. Was Mint EVER vulnerable to the heartbleed bug (which has existed for 2 years) 2. If so, has the SSL cert been revoked and a new one acquired?
Good, stop using it, you're taking up security analyst resources to answer your stupid questions instead of letting them make sure everything is solid.
> You say there's no evidence that customer data was affected, but the heartbleed bug leaves no logs, so that is not re-assuring at all
Well, if they're looking for people making use of the data received by the exploit that is re-assuring..
> You've said before that Mint servers are being updated, which suggests that it was exposed. If this is the case, have you gotten new SSL certificatess? (this is extremely important see next point)
Almost everyone was exposed. I'd like to know they have a new ssl cert too but not because of why you want them to.
> Even if I take a personal precaution and change my Mint and bank account passwords, if a hacker stole your cert at any time and you haven't gotten a new one, all my accounts are STILL vulnerable no matter how many times I change the password. This is because they basically have a permanent back door into Mint until you get a new SSL cert.
No, no they don't I don't think you understand ssl at all.
> Basically, if you don't answer the following questions, we have no choice but to STOP USING MINT FOREVER in order to secure ourselves. 1. Was Mint EVER vulnerable to the heartbleed bug (which has existed for 2 years) 2. If so, has the SSL cert been revoked and a new one acquired?
Good, stop using it, you're taking up security analyst resources to answer your stupid questions instead of letting them make sure everything is solid.
The latest (and final) response Mint gave, 2 hours after this hit the HN front page, is: "I'm terribly sorry for the delay in circling back to this topic. I can confirm that Mint was using a version of OpenSSL that was never vulnerable to Heartbleed."
Seems cleared up. Goes to show yet again, due to the massive traffic it causes, HN continues to be useful as a customer complaint center for egregious cases...
Seems cleared up. Goes to show yet again, due to the massive traffic it causes, HN continues to be useful as a customer complaint center for egregious cases...
Which is the same as their first official response to the thread further up the page too!
Typical mint. Their customer service has been terrible ever since they sold to intuit. I love the service, but the company is terrible.
The absence of a clear response indicates to me that the brass is currently weighing the pros and cons of admitting there was a problem. This is the sort of thing where those who really weren't affected get way out ahead of this sort of thing with vivid detail. I deleted my account.
Seems reasonable, we didn't have to update anything as Centos 5 was using an earlier version without the bug.
They should at least give us some more info, like which openssl version their running (if they use openssl)
That's probably not a great idea - it just instantly confirms them as a viable future target if a bug in that particular version comes up with a hole in it later.
I'm personally okay with "We were not affected by the bug" - random internet people shouldn't have details on the software your company runs internally. One more thing for a potential bad guy to exploit.
Besides, if they'd be willing to lie about being affected, they'd be willing to lie about using a particular version of software, so nothing gained anyways.
I'm personally okay with "We were not affected by the bug" - random internet people shouldn't have details on the software your company runs internally. One more thing for a potential bad guy to exploit.
Besides, if they'd be willing to lie about being affected, they'd be willing to lie about using a particular version of software, so nothing gained anyways.
I agree that they shouldn't publicize which specific other versions of openssl they use/used, but they should be much more forthcoming about what systems (and potentially keys) in their architecture were affected and what data such systems had.
For instance, at my work, we very explicitly said that only two internal systems, our wiki and our issue tracking system, used that version of openssl. Those systems had no user data and had a different set of certs. It is essential to give details. http://blog.taximagic.com/heartbleed/
For instance, at my work, we very explicitly said that only two internal systems, our wiki and our issue tracking system, used that version of openssl. Those systems had no user data and had a different set of certs. It is essential to give details. http://blog.taximagic.com/heartbleed/
If they make a lie that can be proven, they invite liability ($$). If they make an unclear statement and people foolishly trust then to mean more than they say, they skate by. That's why users should always assume the vendor is being intentionally deceptive.
This is mint, for heavens sake, who do all kinds of contortions to downplay the fact that the whole service relies on the having all your passwords and banking details, instead of using their clout to push for sane Oauth-style access tokens for limited access to bank accounts.
This is mint, for heavens sake, who do all kinds of contortions to downplay the fact that the whole service relies on the having all your passwords and banking details, instead of using their clout to push for sane Oauth-style access tokens for limited access to bank accounts.
I still get email from Mint time to time but I've disconnected my bank account. It just didn't feel right, giving away such a crucial information when the local bank already provides means to check your financials. Do I really need to know minute by minute my spendings? Am I spending so fast and so much that I have to watch for my account being emptied on a third party app that is granted access to such intimate data?
Intuit Not giving a Strait answer, next you will tell me water is wet...
Go try to read some some of their dev docs.... I do not believe anyone in the company can give clear and concise responses to anything.
Go try to read some some of their dev docs.... I do not believe anyone in the company can give clear and concise responses to anything.
Just deleted my Mint account; if they're not going to be transparent around this, I flat out can't trust them with my financial information.