Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CryptoCat iOS Application Penetration Test [pdf]

isecpartners.github.io

Post reply on HN
Print view View original

101–110 of 137 posts

Re: CryptoCat iOS Application Penetration Test [pdf]

#101

Post by tptacek »

kaeporan wrote: post #100
moxie wrote: post #99

Earlier quoted context omitted.

To clarify, these audits aren't a choice , they are a contractual obligation as part of receiving grant funding from OTF. Projects are allowed some flexibility in terms of when they schedule it, but it has to be done. I think it's a great idea. Also, during the period of time when TextSecure received audits from firms as part of an OTF grant, publishing the results was not an option that was contractually available t…

Since I am familiar with the process, I know for a fact that OTF asks every project whether they'd like to publish their audits, including TextSecure. That being said, what is stopping you from publishing the audits today?

They do that now. Dan's OTF post suggests that it wasn't always that straightforward, because the auditors had a proprietary interest in their reports.

Re: CryptoCat iOS Application Penetration Test [pdf]

#102

Post by tptacek »

nikcub wrote: post #67
napoleond wrote: post #39

Earlier quoted context omitted.

I can't tell if you actually don't know who commissioned it or if this is your way of suggesting that the parent comment is a lie. It seems like information you would have access to, considering your connection with iSEC, no? (I'm not trying to stir up shit, just genuinely curious.)

Another option is that OTF approached CryptoCat, from where their options would be: a) don't do an audit - and the public would ask what they are hiding b) agree to an audit being done, meaning you 'commissioned' it. So it is just as important to know who approached who in this situation.

One answer, given downthread, might be that the audit was a requirement attached to grant funding from OTF.

Re: CryptoCat iOS Application Penetration Test [pdf]

#103

Post by daira »

tptacek wrote: post #54
kaeporan wrote: post #8

Earlier quoted context omitted.

Thanks for linking to the blog post. This audit concerns a pre-release version of Cryptocat for iPhone. Many of the bugs were due to debugging code and were fixed before release.

Which of the bugs were due to debugging code?

Findings iSEC-RFACC0114-1 and iSEC-RFACC0114-3. (2 out of the 17 vulnerabilities found by iSec, of varying severity.)

Re: CryptoCat iOS Application Penetration Test [pdf]

#104

Post by kaeporan »

tptacek wrote: post #101
kaeporan wrote: post #100

Earlier quoted context omitted.

Since I am familiar with the process, I know for a fact that OTF asks every project whether they'd like to publish their audits, including TextSecure. That being said, what is stopping you from publishing the audits today?

They do that now. Dan's OTF post suggests that it wasn't always that straightforward, because the auditors had a proprietary interest in their reports.

Hmm. Cryptocat was actually the first ever OTF project. I believe they've always asked for the publication of audits.

What I'm curious about is, why don't other projects such as TextSecure publish their audits as well? I'd certainly appreciate Moxie answering this question.

The OTF blog post certainly makes good points for this to happen. I also personally believe that this reticence to publish audits is damaging to the opportunity for the honest evaluation of encryption software and the establishment of a realistic perception of encryption software. It also misleads users.

Re: CryptoCat iOS Application Penetration Test [pdf]

#105

Post by daira »

daira wrote: post #94
primitivesuave wrote: post #12

This is most alarming. CryptoCat's OTR implementation on all platforms allows a chat peer to change their OTR key during a chat session without user notification. An attacker performing a man-in-the-middle attack against the client's XMPP or HTTPS stream can inject their own OTR key in the discussion after a user has authenticated their peer's OTR fingerprint. This permits the attacker to decrypt all messages that foll…

This issue (or one with very similar effect) was also found by the Least Authority audit: https://github.com/cryptocat/cryptocat/issues/607 (The 'issue E' that it references is https://github.com/cryptocat/cryptocat/issues/606 .)

Actually I strongly suggest reading these in conjunction with iSec's issues 12 through 16, because each team spotted some details that the other missed.

Re: CryptoCat iOS Application Penetration Test [pdf]

#106

Post by rancor »

kaeporan wrote: post #93
rancor wrote: post #29

Earlier quoted context omitted.

This point cannot be emphasized enough. In the extreme case, which Cryptocat marketing materials have employed, secure communications software is life safety critical on a level similar to medical or aviation software. As such, the admit-your-mistakes-and-fix-them-later model of development isn't agile, open, or any of those buzzwords. It's a way to get people killed.

Cryptocat has always provided ample warnings that no software can ever be trusted with your life. These warnings appear every time you launch Cryptocat, on the website and in various guides and blog posts.

And I agree, that's a bare minimum warning for all such software. I appreciate your efforts to make strong crypto more accessible to the general public.

That being said, you and I both know that people are using Cryptocat in dangerous situations. And having worked on both medical imaging and secure messaging systems, I have a healthy respect for the consequences of implementation failure. As such, I feel that your disregard for these consequences in broadly releasing such broken software would displease any professional review board, and I frankly doubt you'd ever attain such a license given such a history of poor professional judgment.

In short, I take my profession damn seriously, and jokers like you are why nobody trusts software.

Re: CryptoCat iOS Application Penetration Test [pdf]

#107

Post by marshray »

tptacek wrote: post #74
kaeporan wrote: post #72

Earlier quoted context omitted.

Hi Thomas, OTF provides a form projects like ours can fill to commission this type of audit. So basically, we asked OTF to commission it for us and they accepted. TextSecure, a great encryption app that I've seen you recommend, also approached OTF and obtained an audit from iSEC via this same process. However, TextSecure decided not to publish their audit results. You can read about OTF's reaction to these audits her…

I feel very comfortable recommending TextSecure. TextSecure might be the only secure messaging app I feel that way about. For whatever it's worth: I have no commercial relationship with the TextSecure team, have never worked with them, have never been paid to audit their code, and am only faintly acquainted with Moxie (I've talked to him in person to know that he's extremely pleasant and surprisingly soft spoken, but…

It's really great seeing Trevor contributing on the IETF [TLS] working group mailing list.

Re: CryptoCat iOS Application Penetration Test [pdf]

#108

Post by Tomte »

tptacek wrote: post #55
schoen wrote: post #41

Earlier quoted context omitted.

Are the Matasano crypto challenges currently stuck in some way, like with a grading backlog? I signed up some months ago, sent my first set of answers just after the new year, and have never heard back about the second challenge set.

We are way. way. way. backlogged. If anyone has any idea on how to help a hapless team of security researchers manage many thousands of people looking to get through the crypto challenges, we'd be t-h-r-i-l-l-e-d. We were able to keep up last summer, but then Microcorruption happened, we got into a hole, and we're only slowly digging ourselves out of it. Alex, Sean, and I are turning the challenges into a book, which…

I know I haven't submitted in forever (and may have been removed of the set of active participants), but I got your New Year's bankruptcy mail, but never the "bonus set".

Is that still part of the backlog?

Re: CryptoCat iOS Application Penetration Test [pdf]

#109

Post by Tomte »

ph0rque wrote: post #76
tptacek wrote: post #35

Earlier quoted context omitted.

Why find your way in as a hobby? Are you a professional developer now? Do you like low-level code? Are you OK with jumping directly into the deep end of the pool and maybe drowning a little bit? Why not reach out and talk to us about working on a professional security team? We have gotten very, very good at taking low-level devs and turning them into terrifying killing machines, and if you don't mind having all your…

... if you don't mind having all your flesh removed and your skeletal musculature replaced by pistons and servomotors ... Ah, but have you pen-tested the pistons and servomotors to make sure they're secure against attacks?

I'd be more interested in the safety of those electromechanical components.

Have you developed them under any applicable safety standards?

Otherwise I'd prefer to stay a purely organic organism.

Re: CryptoCat iOS Application Penetration Test [pdf]

#110

Post by sillysaurus3 »

rancor wrote: post #106
kaeporan wrote: post #93

Earlier quoted context omitted.

Cryptocat has always provided ample warnings that no software can ever be trusted with your life. These warnings appear every time you launch Cryptocat, on the website and in various guides and blog posts.

And I agree, that's a bare minimum warning for all such software. I appreciate your efforts to make strong crypto more accessible to the general public. That being said, you and I both know that people are using Cryptocat in dangerous situations. And having worked on both medical imaging and secure messaging systems, I have a healthy respect for the consequences of implementation failure. As such, I feel that your di…

Perhaps we shouldn't call people names?
Post reply on HN