It’s been a year since I released the first and only swedish multi-bank app for iPhone. It’s been pretty successful with some ~45.000 downloads and it’s being downloaded at a rate of 80-100 times per day. When I built the first version I used (and still use today) scraping techniques to authenticate and fetch information from banks. My hope was that it would be more work for banks to try to keep me out by making changes than it was for me updating the app. Looking back it holds true or banks just don’t care about me and my app. I’ve only been in contact with one bank and they actually like my app. Other banks have publicly commented in media on my app saying that using it is comparable to “leaving your home with the keys in the door”. I do think people should be cautious with giving out personal information, but it’s impossible for me to steal money from my users. In fact, I don’t spy on them in any way, and I think that 1 year on the appstore demonstrates this. If I was up to no good by now someone would have investigated and found out.
But this post is about bank API’s and Länsförsäkringar bank in particular. Why are banks not providing real public API’s and let users access their own data? I strongly believe that clever APIs would spawn more smart services that help people get a grip on what they are spending their money on and why they need to stop buying things on credit. Because no bank is currently publicly publishing API’s I decided it’s time to publish some private API’s.
Congratulations Länsförsäkringar bank, you are the FIRST swedish bank with a public API!
Länsförsäkringar bank has built a native smartphone application and it needs an API to provide the data. They have spent some extra time trying to keep you and me for utilizing their API. Todays hacking session resulted in figuring out their API-key algorithm that provide access to the functionality and I’ve documented vital parts of the API.The documentation is available here.
API Token algorithm explained
To call the URL’s that make up the API a special token is required. The way it works is that https://mobil.lansforsakringar.se/appoutlet/security/client returns a number and a “number pair”. The returned JSON-object looks like this:
The number is just a large random number and the number pair is a GUID, most likely the back-end keeps track of issued numbers together with the GUID. By posting to https://mobil.lansforsakringar.se/appoutlet/security/client we get the token back. This is an example of what the API expects to get back:
The hash is the secret that gives us the token. I managed to figure out that the hash is a SHA-1 hash and the value being hashed does not include the challengePair value. The way the algorithm works is:
- Add 4112 to the challenge number. 178263227 + 4112 = 178267339.
- The result is then converted to a string using hex format. 178267339 => aa024cb. The string must be in lower case.
- Hash the hex string using SHA-1 aa024cb => c07389232dd98901d017f05b14de63a66d185042
I hope Länsförsäkringar won’t get too upset about this and instead think about the possibilities in making this API public. Länsförsäkringar is the first bank with a somewhat documented API now but they won’t be alone on the throne for very long. I have already started working on getting into other bank APIs and I will publish documentation on them when I have enough time.
I want to make it clear that I provide information about an API that exist as of right now and that has never been publicly announced. I can not guarantee that everything is correct or that things will not changed. I have only documented what I’ve found out today and I have no affiliation or association with Länsförsäkringar or anyone working there.