Our apologies for the delay in reporting these details and any inconvenience this has caused. We wanted to make sure we fully analyzed the extent of the situation before publishing details
( Read more... )
Agreed. I'm very relieved that it was not as serious of a security issue as it appeared to be, but it was still definitely a security problem. What if the cached page happened to be a payment management page? Even if it doesn't save the credit card number for you to see, there's still a billing address there.
Promises promises, LJ. I want to believe you guys when you talk about improvements to communications and the update process, but I find that I really can't. It's going to take a good bit to get my trust back - would it have been so hard to acknowledge that there was a security issue and that it was actually being looked at? Because we have had no indication until now that the site team was even trying.
some users may have seen pages which appeared as though they were logged in as another random account, but it was actually just a snapshot of the page of the last visitor. It had no effect on security No, of course not: viewing other people's locked entries with random amounts of privilege isn't a security problem at all.
While your rule is a good rule of thumb in general, it's not the right thing to do in a computer security context. When you screw up something in that context, you want to both apologize and then prove that you understand what happened and can prevent it from happening again --- or, if you don't, what you're doing to get there. It looks like that's what they were trying to do here. Whether they were successful or not is another story. It's already pretty bad to claim there was no security effect; if it's true that the vulnerability time was longer than three minutes, this apology is, um, pretty terrible.
Comments 361
Reply
How can you say that when users were able to see other's locked posts, from what those who reported the problem said?
Reply
It may not have had any other consequences than that, but that doesn't stop it being a security problem.
Reply
Promises promises, LJ. I want to believe you guys when you talk about improvements to communications and the update process, but I find that I really can't. It's going to take a good bit to get my trust back - would it have been so hard to acknowledge that there was a security issue and that it was actually being looked at? Because we have had no indication until now that the site team was even trying.
Reply
Reply
Reply
Reply
Reply
Nor can my client (Semagic) load history any longer.
Reply
No, of course not: viewing other people's locked entries with random amounts of privilege isn't a security problem at all.
The truth: it's not just for breakfast any more.
Reply
Reply
Reply
While your rule is a good rule of thumb in general, it's not the right thing to do in a computer security context. When you screw up something in that context, you want to both apologize and then prove that you understand what happened and can prevent it from happening again --- or, if you don't, what you're doing to get there. It looks like that's what they were trying to do here. Whether they were successful or not is another story. It's already pretty bad to claim there was no security effect; if it's true that the vulnerability time was longer than three minutes, this apology is, um, pretty terrible.
Reply
Reply
Leave a comment