Interview: Tim Messerschmidt, PayPal

Many Habr's readers listened to the report of Tim Messershmidt, who is responsible for PayPal communications with developers in Europe, the Middle East and Africa at the recent MBLTDev conference. It was about authentication and the difficulties faced by experts, trying to protect user data. The technical director of Redmadrobot, Arthur Sakharov, mc_murphy caught Tim behind the scenes of the event and talked to him about security, jailbreak and programming languages.

In your speech, you talked a lot about the fact that the quality of UX often conflicts with security - especially when it comes to sensitive information, such as banking applications. Tell about it, please, in more detail.
In PayPal, we use two-factor authentication: when confirming a new device, we use its hardware identifiers and confirm them with one-time access codes that are sent via SMS. When a user registers, he also receives an email asking him to confirm authorization. That is, we offer a range of security solutions in addition to the usual registration and subsequent login using a password.

Let us be frank: if you have a complex password, this is good. But we must understand that the passwords of most users are not very secure. And then - be aware of the likelihood of sorting through possible combinations for a password, which works fine, since most users use the same popular passwords. You can reduce the risk of attacks by forcing them to invent long passwords. And we really see a trend: people use stronger passwords when they realize that information is important and needs protection. These are banking applications, PayPal, Google, eBay, as well as those services that are subsequently supposed to be used for Single Sign-On.

You can come up with a strong password for some kind of service, but it is unlikely to provide one hundred percent protection. After all, the purpose of phishing attacks is often the user's email, and the mailbox contains critical information and is the “key” to all other services. It turns out that if I use the banking application in conjunction with the email - it is not particularly reliable.
Of course, I do not recommend registration or authentication via email in the case of banking applications. I would probably make a choice in favor of a hardware token, because when using a software token, the data can still be sidelined. Even if you receive an SMS with a code on an Android smartphone, this is not very reliable - after all, other applications can intercept it.
')
I know you like Android. Let's talk about Android and iOS in the security context. Whose approach is more effective?
iOS is a more closed system, it has more restrictions. And in some cases this is a big plus. As for Android, there are a lot of positive changes in terms of security. The system becomes more reliable: it is more and more difficult for attackers to gain access to Android devices. SELinux is used, where the kernel is much better protected. Now, without fear, it can be argued that Android applications have become truly protected, and Google takes security on Google Play very seriously.
However, this is not true for all devices, besides Google Play is not the only source of applications. For example, in Germany, as in many other countries, the device is often tied to a specific operator, who also has its own application store. From a security point of view, their quality does not necessarily correspond to the level of Google Play.
You can hardly blame only Android here, because for third-party applications the same system is now used there as in iOS: there is TestFlight, there is HockeyApp, developers can sign the code for distribution to testers without additional control. It turns out that 3000 people at a time [limit on the number of testers in TestFlight] can get a malicious application.

What do you think about jailbreak? This is a serious security threat. Maybe we should ban its use on the side of the application? Or can you protect the owners of jailbreak devices in other ways?
This topic is close to me and interesting! Before joining PayPal, I jailbreaked while writing a diploma. On the one hand, with a jailbreak the user has more freedom in controlling the device: in some situations this can be useful, which should be taken into account. However, it’s pretty easy for a developer to determine if there is root access on the device and deny everything. You can run something from under sudo, you can check the signatures of the application code for changes. There are opportunities to learn all this: Android is generally a simple system. However, the same applies to iOS - for example, you can check whether Cydia, etc., is installed.

Of course, we take all this into account when developing banking applications. But some users stubbornly want to jailbreak, want to have root access.
Yes, for some applications jailbreak is really necessary. For example, if you use emulators on iOS and other similar things. I think in the case of banking applications it all depends on how many users use root access, and how many do not. You may have to sacrifice the share that has it, for the sake of security.

What do you think about CAPTCHA and other methods for identifying password guessing?
Image recognition technology is rapidly improving. Of course, as long as the machine is not able to read any CAPTCHA, but hundreds of them may already be. Therefore, such methods of protection should be avoided or used only as an additional measure. In general, most CAPTCHA users are frustrating, and often, frankly, do not justify the hopes that are placed on it.

I agree with you. One can hardly be considered a reliable tool for checking, which is easier to crack every day. And how do you feel about the concept of “Security through obscurity" ? There are well-known algorithms: SSL / TLS, etc., but you can always add something of your own. Do you recommend using such protection in applications or not?
By itself. First, there are automated ways to obfuscate code, for example, ProGuard . Secondly, you can use your own client certificates when interacting with the server. Further, there is an EventBus message bus, and if you use ProtoBuf- type protocols when transmitting them, it will be quite difficult to read this data in binary form, because class specifications are required for decoding. If you implement all of this, then the system will be pretty strongly protected.
Nevertheless, it is obvious that any code can be decompiled, and even the most complex obfuscation leaves it possible to understand what is happening in the code. Therefore, I usually simply advise you to make the code as complex as possible in various ways, but at the same time remember that, unfortunately, there is almost always someone smarter and will understand what is there.

Partnership with PayPal is interesting to many. What are the possibilities of its technical implementation?
Of course, for developers we have an SDK. But if we talk about the IT industry, banks, large corporations, the possibilities are wider. A good example here is the Microsoft Xbox. PayPal is integrated into Xbox Live directly through access to our API. Major partners, we are ready to provide access to the API.

Tell us, do you use Scala in PayPal? Are there any plans for him to go?
No, we use native java. The point is not that Scala is a bad language. It's easier for us to find qualified engineers who know Java. At one time, almost all PayPal was written in C ++ and Java, now we use Node.js and, of course, JavaScript. As a result, our backend is quite flexible. PayPal is a SaaS service, and much of its infrastructure is geared towards using the API. If desired, the team can write a project on Go - in our company it is actively used - in Python, ELAN, Haskell, as you wish. But for Android, we use native Java.
I think Google has good reasons for not promoting Scala or another alternative language. They have a Dart , Microsoft, for example, has a TypeScript. But on Windows Phone, there is no support for TypeScript, nor is there any support for Scala on Android. I think the point is that these languages ​​are not quite mature yet. I am not sure that Google will promote Scala at all. Yes, its undoubted advantage is that it works on the JVM, but Dart is still their own development.
In this case, Apple looks more confident in its own language and choosing it for the platform, so, to sum up, I’ll say: I would rather use Swift on iOS than Scala on Android.