Live data from Hacker News

Open-sourcing Tutanota: Why it was important to us

tutanota.de

51–60 of 64 posts

Re: Open-sourcing Tutanota: Why it was important to us

#51

Earlier quoted context omitted.

So we have an FAQ link which amounts to "too many clients have bugs around spaces in passwords". I'm not as certain that this is true as it was when we instituted that rule, but it definitely was at the time. As for the autogenerated password thing. You might have followed that Google are making it more and more difficult to "just use your very secure password everywhere" as well, because they find that it leads to a…

I'll say the same thing I said in the bug: I can appreciate the problem of people using clients that are broken, but why does this matter here? Thunderbird is not among them. So why are we discussing whether a customer would be able to successfully use their client to access the account of someone else who has spaces in their password? (Also, could you share the data you have about those clients?) > You might have fo…

Google are doing it because the risk landscape has shifted from people signing up fraudulent accounts to people stealing existing accounts in good standing and using them to spam. You can rate restrict new free-trial accounts, but it's harder to rate limit long standing good accounts without annoying legitimate users - but once their account is stolen, that means a fair bit of spam can get out before reports come back or we can block the limit.

The zero point something percent comment - most users aren't at your level of proficiency - and we do have to play the percentages here. If 10% of our users get phished and their accounts used for spam, you can't send email reliably through us any more because we'll be on every blocklist in existence.

The vector for accounts being stolen is almost never weak passwords - it's phishing or viruses or password reuse. We just don't see people enumerating passwords. You flat out don't need a super strong password, it makes no difference beyond not using one of the top 1000 most common passwords (unless our entire password DB gets stolen, but that's a different class of risk - whole system vs individual)

Well, we can't guarantee that you don't go ahead and use it on another service of course, but by generating the device access token ourselves, we can be sure that you aren't reusing a password that you are using somewhere else.

You can already do this yourself, we support alternative logins, including one-time passwords - but as I said, it's about the percentages, we need to make it easier for average people so that more accounts are more secure.

Re: Open-sourcing Tutanota: Why it was important to us

#52

Earlier quoted context omitted.

So we have an FAQ link which amounts to "too many clients have bugs around spaces in passwords". I'm not as certain that this is true as it was when we instituted that rule, but it definitely was at the time. As for the autogenerated password thing. You might have followed that Google are making it more and more difficult to "just use your very secure password everywhere" as well, because they find that it leads to a…

I'll say the same thing I said in the bug: I can appreciate the problem of people using clients that are broken, but why does this matter here? Thunderbird is not among them. So why are we discussing whether a customer would be able to successfully use their client to access the account of someone else who has spaces in their password? (Also, could you share the data you have about those clients?) > You might have fo…

Carussell: have you ever worked in first-line support?

To paraphrase a friend: "If I never hear the phrase: Why isn't my email working? I have an iphone...", I'll die happy."

I can appreciate that it's nice to be able to use space as a character, any reason you can't just substitute "." or "," on mobile (in terms of UX, obviously)?

Btw, I have no affiliation with fastmail.

> and guarnteed non-password-reuse of device passwords.

This should be easy to guarantee at creation-time:

  For user A, all devices a...x
  When generating a new device password p
  Check p against all historical device passwords
    for devices a..x
  If no match, use p
  Else generate p' and try again
When a valid (non-reuse) password has been found, it can be stored in non-reversible form (salt+hash, optional stretching).

I would too like to know what fastmail actually do, though.

Re: Open-sourcing Tutanota: Why it was important to us

#53

Highly secure messaging, email, and Internet services has a long history in military and defense sector with issues well-understood. I mention here [1] the framework I used in high assurance security engineering. The system must be built using strongest engineering techniques with the right requirements. It must run on an endpoint with specialist security engineering techniques resistant to talented hackers. The prot…

Hadn't heard about tinfoil chat before, thanks for the link. He also seem to have an ambitious project for email:

https://github.com/maqp/tfe

"When the serial cable used to transmit information between two computers is enforced with an RS-232 data diode to funciton in unidirectional fashion, exfiltration of encryption and signing keys without physical access becomes impossible."

Right. Or use a smart-card. I'm not sure it's more sane to trust a typical pc to not have a hw backdoor (eg: intel managment cpu with wlan access -- does need to be enabled in bios. At least that's what Intel says) -- rather than trust a smart-card (idea is to send data to card, get signed/encrypted data back. Keys never leave card).

Interesting idea though.

Similar ideas for a pair of plugins for pidgin:

https://github.com/maqp/tfc-cev

The modules look huge though. Plenty of room for someone to slip in a listening device with burst-capable transmission. I don't think the actual security is much higher than just using a smartcard?

Re: Open-sourcing Tutanota: Why it was important to us

#54
post #53

Highly secure messaging, email, and Internet services has a long history in military and defense sector with issues well-understood. I mention here [1] the framework I used in high assurance security engineering. The system must be built using strongest engineering techniques with the right requirements. It must run on an endpoint with specialist security engineering techniques resistant to talented hackers. The prot…

Hadn't heard about tinfoil chat before, thanks for the link. He also seem to have an ambitious project for email: https://github.com/maqp/tfe "When the serial cable used to transmit information between two computers is enforced with an RS-232 data diode to funciton in unidirectional fashion, exfiltration of encryption and signing keys without physical access becomes impossible." Right. Or use a smart-card. I'm not su…

The smart-card vendors might be working with any number of people. You can't be sure and subversion is at an all time high. The reason he used our data diode recommendation was you can use arbitrary hardware for the send, receive, and network nodes. Receiver can't leak anything outward even if hit by malware. Sender can't receive attacks from Internet. And network can be toast without ill effect. This can be verified by looking at the wires you modified rather than giving ChipWorks millions to R.E. it. ;)

Later we told him OTP wasn't going to get takeup. I described my cascading cipher. That led to his multiple encryption etc version. I told him high assurance crypto NSA uses defeats covert channels with (a) fixed sized transmissions, (b) fixed rate transmissions and (c) not letting errors have a visible effect on that. Goes way back. He changed it to do that.

So, he was clever with the design and has been responsive to updates. Those are just a few I remember. He used Python because it's easy to read. He only has so much time for the project. Other stuff I suggested included converting it to a language like C, Ada, or Pascal for control over memory & extra visibility. Also, using the Dresden Nizza architecture (or MILS architecture) on transport and sending stack to further enforce isolation and secure decomposition. More work to be done but it's a nice executable specification of something that can give NSA hell with low end equipment.

Far as email, that must be a side project he started as a result of some of us suggesting he port GPG or something to the architecture. I'm not familiar with it. I only endorse main chat architecture with encouragement that implementation keeps improving. :)

Re: Open-sourcing Tutanota: Why it was important to us

#55
post #53

Earlier quoted context omitted.

Hadn't heard about tinfoil chat before, thanks for the link. He also seem to have an ambitious project for email: https://github.com/maqp/tfe "When the serial cable used to transmit information between two computers is enforced with an RS-232 data diode to funciton in unidirectional fashion, exfiltration of encryption and signing keys without physical access becomes impossible." Right. Or use a smart-card. I'm not su…

The smart-card vendors might be working with any number of people. You can't be sure and subversion is at an all time high. The reason he used our data diode recommendation was you can use arbitrary hardware for the send, receive, and network nodes. Receiver can't leak anything outward even if hit by malware. Sender can't receive attacks from Internet. And network can be toast without ill effect. This can be verified…

Oh, don't get my wrong. I think the project is interesting, and it's obvious open hw is the way to go - especially if the design can be kept both simple and useful.

I don't really see anything wrong with having the cable be shorter (ie: an open platform smart card).

Lets just say that from a practical standpoint, I'd be much more interested in getting "most" people to use s/mime and/or gpg with keys and encryption on a dedicated device -- no matter if that device is a re-purposed Android without a baseband chip, running some open Linux based OS (full distro or something like Replicant) -- or it is a smart card, or some kind of dedicated open hardware.

The cascading idea is interesting, but probably more useful in a more adversarial scenario than most people need. Good for running drugs, or a revolution (or insurgency) though ;-)

On a serious note, I do see some real overlap between this military grade approach and "normal" use-cases. Especially for people that find them selves at odds with their government. Be that FBI targeting #occupy in Zuccotti Park, the German intelligence services/NSA spying on elected officials in Germany -- or people opposed to current policies in China, or advocating gay rights in Russia.

We live in a time where there's enough oppression to go around :-(

Re: Open-sourcing Tutanota: Why it was important to us

#56
post #31

Earlier quoted context omitted.

FastMail isn't based in the US (we are in Melbourne, Australia). For those who will point out that some of our servers are in the US, see: http://blog.fastmail.com/2014/12/15/security-confidentiality/ For those who will point out about the new Australian data retention laws: http://blog.fastmail.com/2015/04/09/fastmail-is-not-required-to-implement-the-australian-metadata-retention-laws/

Not just 'some' of your servers. Looks like infrastructure is US based. https://www.fastmail.com/help/ourservice/security.html Physical location security Our main servers are located at New York Internet (NYI) in New York City, USA. Their facility is a high security, video monitored location; with backup power, air conditioning, fire systems, 24x7x365 monitoring, and onsite technical support. I am familiar with NYI -…

> Our main servers

"main" servers. Most services are mastered at NYI, with replicas at other sites (currently Amsterdam, soon LA as well). Soon some services will have the option of being mastered elsewhere. Maybe I should reword that help doc a little bit.

Our security is about as good as is practicable. It might not be the absolute best but I'd wager its better than most, especially when balanced with the usability and reliability guarantees we make. Obviously encasing your server in concrete and dropping it into the ocean is more secure, but that doesn't give you much of a service.

I don't think I can say NYI do better than every other datacentre, because I haven't used ever other datacentre, but they certainly seem to be far above most other players. It also helps that we've worked with them for years and know most of the key staff personally.

We don't currently encrypt traffic between our servers within the same datacentre. We own all our servers and network equipment, so there's no inter-server traffic leaving our own equipment. Of course its possible for some kind of network tap device to be installed but at that point the attacker already has physical access to our servers so we've already lost. This point was addressed in the first blog post alfiedotwtf linked to.

We do encrypt between datacentres, of course.

So to your final question, what differentiates us from other services, its hard to say exactly because I don't know which other services you're talking about. Our general approach is to use the best tools and techniques available, and to understand everything we use so we know what compromises we're making at what our attack surface looks like. Our ops staff know this stuff well, respond quickly (eg we patched Heartbleed before start-of-business in the US, when most of the mainstream media hadn't picked it up yet), we talk very openly about what we do and how we do it, and we offer a generous security bounty to anyone that finds an exploit.

If you think we could be doing more, let me know! I'm happy to be contacted directly (robn@fastmail.com or @robn on twitter) or you can open a support ticket or ping @fastmailfm.

Re: Open-sourcing Tutanota: Why it was important to us

#57
post #55

Earlier quoted context omitted.

The smart-card vendors might be working with any number of people. You can't be sure and subversion is at an all time high. The reason he used our data diode recommendation was you can use arbitrary hardware for the send, receive, and network nodes. Receiver can't leak anything outward even if hit by malware. Sender can't receive attacks from Internet. And network can be toast without ill effect. This can be verified…

Oh, don't get my wrong. I think the project is interesting, and it's obvious open hw is the way to go - especially if the design can be kept both simple and useful. I don't really see anything wrong with having the cable be shorter (ie: an open platform smart card). Lets just say that from a practical standpoint, I'd be much more interested in getting "most" people to use s/mime and/or gpg with keys and encryption on…

The cable is just what he had at his house: a smaller one is better. Not sure why you keep bringing up smartcards as alternative to long cable: two totally different things. Only realistic alternative to his cable w/out extra risk is point-to-point IR transfer: cheap & hard to grab if nearby (unlike Bluetooth/Wifi).

It would be nice to get more people on GPG or Linux. It's what I use, too. The problem is their Trusted Computing Base [1] is ridiculously huge. Even amateurs regularly break NIX systems, browsers, and so on. The methods for designing things highly resistant to attack are out of reach for most projects. See my framework [2], for example, to see the gap between high quality coding and truly secure systems. Most developers, even many security "pro's," have no idea about so many of these things. Just ask anyone building one of these "NSA-proof" crypto tools to see their Covert Channel Analysis with breakdown of all residual storage, timing, and resource exhaustion channels. Observe the blank or confused stares.

So, Markus was trying to shortcut around that using concepts he learned and we discussed. It had to be provably immune to software attack despite weaknesses in components. GPG on Linux/Android means GPG or Linux/Android must be breached. Although GPG is solid, Linux/Android breaches abound because they're insecure crap. So, that won't work against event a good black hat. He couldn't build a High Assurance Guard [3] by himself so he had to eliminate almost whole TCB. TFC was a clever workaround. TFC and Linux/Android-based clients have no comparison given only one can make a strong security argument under all conditions of software attack and the others just have so many real-world attacks... Apple to oranges, my friend.

For cascading, it might be overkill and might not. Note that many real-world algorithms working in isolation had problems. Cryptophone used a AES + Twofish cascade as insurance. The idea is that one algorithm or trick failing won't compromise the system. It applies to regular crypto users as much as anyone else given we use same algorithms. I agree it might not be necessary for majority of people, though. They use Gmail or Facebook over HTTPS for their critical communications. Clearly different privacy needs, there. ;)

I agree on the overlap: it's why I push the strong stuff. :) The reason, though, is that all the bad guys aim for the same thing. Plus, the nation-state methods (esp firmware attacks) are starting to be used by non-nation-states. The methods for stopping software attacks by nation-states are same as for anyone else. It's why our systems need to be redone (example [4]) to simply enforce fundamental protections to stop all that shit. And meanwhile, we have to use GPG, TFC, air gaps, and other kludgy solutions to make up for how bad we have it.

[1] https://en.wikipedia.org/wiki/Trusted_computing_base

[2] http://www.schneier.com/blog/archives/2013/01/essay_on_fbi-m...

[3] https://en.wikipedia.org/wiki/Guard_%28information_security%...

[4] http://www.crash-safe.org/assets/ieee-hst-2013-paper.pdf

Re: Open-sourcing Tutanota: Why it was important to us

#58
post #39

I think this service proves the lack of value of code review or code release in isolation. They give you the option to save your login on a "private computer", which stores a cookie that will be sent over non-encrypted connections. Which means that if the user connects to a wifi connection that you control, you can trivially inject something which will cause the browser to make a http connection to www.tutanota.com a…

I'm not a Fastmail fan, but it's sad that what appears to be the only substantive technical commentary about Tutanota on this thread has been voted down by people who can't see past tit-for-tat between email services. Tutanota exists to provide security , and appears to do so poorly. That seems like one of the more relevant things to discuss.

> I'm not a Fastmail fan

Curious: is that just a personal preference? I still use Google Apps for almost everything, but have a couple domains on Fastmail and have been extremely happy with their service. I have often considered moving more of my business there, and would greatly appreciate a substantive warning if it's warranted.

Re: Open-sourcing Tutanota: Why it was important to us

#59
post #39

Earlier quoted context omitted.

I'm not a Fastmail fan, but it's sad that what appears to be the only substantive technical commentary about Tutanota on this thread has been voted down by people who can't see past tit-for-tat between email services. Tutanota exists to provide security , and appears to do so poorly. That seems like one of the more relevant things to discuss.

> I'm not a Fastmail fan Curious: is that just a personal preference? I still use Google Apps for almost everything, but have a couple domains on Fastmail and have been extremely happy with their service. I have often considered moving more of my business there, and would greatly appreciate a substantive warning if it's warranted.

I trust Google's security team more than almost any other security team, and I trust Google's lawyers even more.

Re: Open-sourcing Tutanota: Why it was important to us

#60
post #55

Earlier quoted context omitted.

Oh, don't get my wrong. I think the project is interesting, and it's obvious open hw is the way to go - especially if the design can be kept both simple and useful. I don't really see anything wrong with having the cable be shorter (ie: an open platform smart card). Lets just say that from a practical standpoint, I'd be much more interested in getting "most" people to use s/mime and/or gpg with keys and encryption on…

The cable is just what he had at his house: a smaller one is better. Not sure why you keep bringing up smartcards as alternative to long cable: two totally different things. Only realistic alternative to his cable w/out extra risk is point-to-point IR transfer: cheap & hard to grab if nearby (unlike Bluetooth/Wifi). It would be nice to get more people on GPG or Linux. It's what I use, too. The problem is their Truste…

> The cable is just what he had at his house: a smaller one is better. Not sure why you keep bringing up smartcards as alternative to long cable: two totally different things.

True, a smart card doesn't give you separate input/output terminals. But it can isolate the key and encryption bit. It can be quite secure in case of theft, off-line access.

[ed: I wasn't talking about just the cable, I was thinking about all the devices soldered into it. They look big enough for there to be a possibility to embed a listening device. That is if you're a direct target by something like the Egyptian Secret Police etc]

Certainly this system has different and stronger security properties -- but also usability issues (even if you could probably sandwich most of it into a single laptop case. Would be interesting to have two screens side-by-side for input and output).

Do you know anything about throughput for this? Would it be viable for high-quality video chat?

> TFC and Linux/Android-based clients have no comparison given only one can make a strong security argument under all conditions of software attack and the others just have so many real-world attacks... Apple to oranges, my friend.

I meant and Android hw device, similar to running a stripped down OS on pc hardware. Sort of as a replacement for the hw in the terminals used here. I didn't mean a full Android software stack. Preferably a system without baseband, networking etc.

I'm not sure about your use of "NIX" here. Is this a combined hardware/software platform? Google wasn't very helpful.

It is of course true that if you can compromise the keyboard, display driver, kernel, i/o for gpg etc -- you can actively compromise the system.

As far as I know, typical Linux/bsd installs are not vulnerable to compromise either via a usb stick or via tcp/ip (assuming updates are disabled). So it would seem that using a dedicated (mostly) air-gapped laptop would practically be as secure. In such a case, keeping keys/crypto on an open-hw smartcard might be a prudent extra step that would add a little more security against certain threats.

> For cascading, it might be overkill and might not.

As long as one can show that cascading doesn't weaken the system (eg: perhaps a construction opened up some kind of oracle, along the lines of compression+encryption, perhaps key derivation would leak information on a master secret if one uses related keys) -- I don't see much of a reason not to.

On the other hand, if you double the number of crypto systems in use, you double the number of bugs. Of course, it might be that the attacker can't attack bugs in the inner systems easily, so perhaps by layering you get to choose which system are most easily exploited...

Either way, I think both an air-gapped computer+smartcard and this system would be secure enough, that if you are a target, someone might want to try and sell you special, compromised hardware. It might not compromise the system as such, but even just a microphone+transmitter in any one of the components might be enough to pick up sounds of typing, and be able to infer plaintext. Not sure what the easiest way to read the screen would be, but probably some kind of signal leakage from the gpu/cable/screen.

Post reply on HN