Hello, my name is Juan. I'm a, I'm a engineer director. I lead the access management team for Cash App. My team owns authentication, authorization, all the security posture, all the bad things that people do to the app, all the fraud and everything. And I'm here to talk a little bit about our journey to adopt Past Key and maybe share some lessons that we, we learned along the way. So first of all, a little bit introduction because Cash app is not widely used in Europe yet where live, where live in UK but in the US is a very widely known in. This is a, a screenshot of the download chart on iOS. We're number one in the finance category, is start out as p2p peer to peer payment app and can see ahead of Venmo or PayPal our competitor in the P2P space. And if you look at the overall download chart is still up there too along with Google Map and Facebook and even more downloads than Spotify in the us.
So a lot of people use app because we evolved over the last 10 years from P2P app to a full financial platform, a banking app and it offers Bitcoin banking, stock investment loan you can do. We also do lending and merchant, we have merchants accounts, we also have Cash app pay as well. So full fresh, the financial services app designed for the under banking community data. They don't need to have a bank account, they can just download a cash app. It's important to talk a little bit about our history. 10 years ago we started as a P2P app and oh, I actually wanted to touch a little bit on the, our benefit of being a number one financial app is not user use it, but I also wanted to touch upon downside of being the number one financial app that is that we are a big magnet for attackers.
So we see a lot of people proactively attacking us because there's real financial incentive behind it and if they could take over the account, they can drain the balance, they can get a lot of financial benefit out of it because of that P2P origin. In 10 years ago when we started out we wanted to make payment really easy. It just need an email address or phone number and be able to pay somebody money and be able to withdraw all that. We built experience around a passwordless experience back then 10 years ago and we knew this is gonna be a native app. We don't want people to transact our mobile phones. We all have fat fingers. We don't wanna tap 10 digits with uppercase, lowercase or the special characters. So the experience is actually very simple and persist today. It's to essentially you log in with the otp, either your phone number or email, I will send you a code and you log in and if it's on the device that we recognize already, we just let you log in.
But if you switch to the new device or you log in for the first time, we try to do MFAs and maybe prompt second factor to let you in. So very simple user experience but the the complexity is not on the front end. The user interface is very e easy, but reality is my team is very big because there's a lot of complexity on the backend. There's a, there's a whole system in the backend that we evaluate every login. This is a, we essentially implement continuous authentication way before that become a buzzword and we have a whole system in the backend to continuously look for signals and looking at a possibility of attack and flag them. And this is not just a system that you may heard elsewhere, like a static system that's sort do risk detection is actually ongoing loop. There's a big team of operation experts.
They look at these attacks and they trend different models. We continue to evaluate the, evolve the models over time. The reason is because this is simply a cat and mouse game. Whenever we calm down some pattern attacker gonna come up with some new things and we need to continue to watch and evolve to see what's going on and train our model adapt to that. So all that complexity is is part of the journey today. But we also build a bunch of other features in order to give user better control. There's a device management, they're proactive notification and we also have a biometric unlock re relock app. All the features built trying to enhance the security. But all of these things are in my mind are extra work that we have to do just because of the factor we use is not that secure. Like SMS is subject to sim hijacking.
We all previous speakers talk about the email. It's also subject to hijack hacking, getting the OTP code so there's not very secure method and phone number also can be recycled. And because of that problem we'll have to build all this other system around it in order to secure user account. So very much in the future we wanted to get to a model of adopting phishing resistant technology and rebuild this passwordless experience switching from OTP in order eventually get to the pass key based experience and completely remove phishing as a attack vector. Today we see all sort of phishing attack. We've seen so many different ways user attacker can trick our user to believe that they are the authenticate, maybe a cash app rep et cetera give out the passcode, OTP and logging in. And so in the future I'm hoping to get to a point where I can downsize that, that risk team and hopefully one day completely eliminate that if we can transition to the sufficient resistant path.
And so some this talks about some of the things that we learned along the way adopting paske and wanted to share some insights and you need to be aware of and hopefully help you when you're trying to go on this path adopting paske as you're fishing resistant mechanism. And if you're using idp, this is a a question more for IDP to implement. But if you implement that natively as we do, this is probably to your heart, but even if you use idp, this is the questions that you wanted to ask the IDP to make sure they taking these internal cons consideration. First thing is wanted to talk a little bit about platform variability and it is light today when Google and Apple tells you that pasky is very easy to use, it's gonna seamless a port from platform to platform. The reality is a lot more complicated.
And first of all, Google hasn't released their past key official support yet. They've been promising that for a while. But even if after Google release it, if you look at the their solution, they essentially just solve that problem within the Android ecosystem. So if you use Chrome on Android and use native app on Android, now you have a little bit portability, you have clear one key, it will show up on the browser versus on the native device. But if you look at Chrome browser across devices, across ecosystem, the story is very fragmented. Our windows, obviously everything's isolated Windows pretty late into implementing the platform support and on even on Mac os your your Mac, your Chrome browser is in completely different silo. Even Apple controlling the complete ecosystem, they promise the seamless use user experience key can port across different application. That's also sort of a lie.
Most, a lot of people use Chrome or Window edge on Mac computer. They actually don't share the key if you use it on native device, this is a separate silo and that's the reality today is there's a lot of implementation hurdle platform evolvement that need to happen. But today that's a reality. What that means for all of us is we should recognize this is very different from password. If you, especially when you migrating from password to passwordless, one thing to re realize is there's only one password. I don't know if you've ever seen a website where it says you can enter a second password or fallback password. The moment you change password, the old password is gone, the server only maintain one copy. But the reality for pass key is there're gonna be multiple pass keys for long, long time to come. And that means you, the implication is you need to manage these multiple keys.
There's not a single password for you to manage but for each user you're gonna have a multiple key that you have to manage. And my advice there is making sure that you capture enough contextual information for these keys to differentiate among them which platform they were created on, what, what time they were created on. And I ideally in some use cases, I've seen people even prompt user to say give give a name to this key. When you create this additional key and you want to differentiate the amount them, part of the reason you want do this differentiation is you want to give user better experience and you want to do some sort of platform detection when they log in from a different platform than where they create a key from. You wanna be a little bit more intelligent, don't problem the key that they for sure don't, they don't have.
Even if you know it's a roaming key, you, it will benefit from a little bit detection. You tell the user, well I've seen you create a key on this other platform. Maybe try the roaming authenticator. The the second area I want you to think about is the lower security guarantee from the old Fido standard when we introduced the past. Key one is between the, between the old FI and the new PAs key introduction, there's a fundamental change in the past it's called single device credential. It's the key is always stored in hardware. And hardware has this nice property that you can never export that private key. So you know for sure it's safe and with the introduction of the PAs key for sure in the future is right, you can port your key across different platforms but it also come with the downside that it's now in software.
So NIST has this nice framework thinking about security, a different level of security. This AAL 1, 2, 3 and I won't bore you with the detail but largely when you move to pass key you downgrade to AAL two level. For us being a financial app, we strive for the highest level per security needed. So we're trying to get that level of AAL three assurance possible. So this is not a picture you of the security trade off between between the different options and there is a proposal still in draft form called the Dpk device public key that could try to bridge the gap up the security standard a little bit toward closer to AL three. So that's the second to the right box that sort of trying to improve that. This point about hardware versus software is not purely theoretical exercise. It actually is real that in software you can do a lot of crazy things and Apple actually implemented this feature and they advertise it.
You can airdrop a key to somebody else. So the moment you give user the choice, you'll know some user gonna make mistake. And so that's the reality that now you lose the property that Harvard guarantees you, the key can never leave your device. There is real probability that key be shared, be leaked. So solution wise I won't get into detail but the idea around that is yourself. One minute left. Cool. So I want borrowing with the detail essentially track your devices then could potentially leverage solution leverage DPT kind of capability. So the other thing I wanted to mention is how is different from a password and we talked about there's one password et cetera, but also there's another facet with password. There's only one artifact, but with passkey there are two, there're a private key and public key one's on the client side, one's on the service side.
And so this is important to recognize because they could get out of sync, you don't control the client site. User can delete their private key but you control the public key. You could allow the user to remove public key, but then those two things could get out of thick sync and you need to be a little bit intelligent about how to manage the sync. When they get out of sync. You need to be able to prompt the user, let them know what's happening. User's not gonna understand their private public key. Even password is harder for them to understand and skip that. Lastly, I wanted to mention that this is a transition. This is not flip of switch. Switching to Pasky is very hard. A lot of involved user education. This is one on the app. I took a screenshot. This is a level extent they go to to, to talk about what the pasky is.
I'm hoping at the given part of the goal of giving this talk is get all of you excited about the technology and all of us adopt that technology over time. It takes a lot of user educations to get them understand the technology and if we all adopt the technology, we have a better chance collectively educate the user. Today, sadly a lot of people don't even understand biometric. We see a lot of people turning off biometric capability. So there's a long road ahead for us to educate users and also talk early speaker, talk about big build, big backup plan. You don't wanna have weak attack vector. So that concludes my talk. I Richard just wanna highlight a few issues for you to think about and I'm not going too much detail, but hopefully we are all on the same journey and there's the future for pasties, right? We can really bring a lot of security benefit to all of us.
