Klarna users are being signed in to random accounts (opens in new tab)

Good to hear, I failed an interview with them at the sixth step or so because I make a point not to remember easily googleable trivia, bet their engineers are traversing rb trees on paper off memory like crazy right now trying to find a solution

In Sweden you can ask them to require Mobilt BankID confirmation to every buy, their competitors (like qliro) don't have that yet so Klarna are only half bastards. But they did get a lot of criticism from the Swedish government about the same things you have presented.

The actual victim of the fraud is the creditor who was defrauded by the criminal; they are just leveraging the unfair legal system to push the liability onto someone who was not party to the fraud in any way (the person whose name was used in the fraud by the criminal against Klarna).

This is the lie of "identity theft". It's not identity theft, it's money/goods fraud, from a bank that didn't do proper authentication.

I am not sure this makes sense. Shouldn't Klarna provide proof of the transaction to the court? Won't the court look at it and throw it out as baseless? If Klarna were actually on the hook for their own money, it wold only have to happen a few times before they realize it's not worth it. edit: definitely not a finnish lawyer

This reminds me of this BBC article I came across: https://www.bbc.co.uk/news/business-55829879

> To use Klarna's pay later service, which defers payments for up to 30 days, shoppers only have to provide a name, email, date of birth, mobile number and billing address.

It’s mind blowing that’s all the information you need to process a payment via Klarna.

This is one of the reasons I wish governments in the world implement proper digital authentication instead of relying on static identifiers like name, address, or SSN.

Yeah but what about the saved traffic? Think of the poor routers that have to do all this transferring job.

Reminds me of a primitive web filter at work that blocked me from something. So I look at the URL, add an “s” to http and voila. I think they MITM everything now.

Something similar happened a few years ago in Norway, when the yearly tax returns were released. Everyone of course logs in at the same time. It goes down, and the cache serves someone else's data instead.

I would expect this to happen if an option in the line of "serve stale content if target server is unreachable" is enabled.

Ouch.

> "Why would anyone do that?"

That's such a typical Swedish answer... but they do allow (but not as default!) to block orders and request digital confirmation

Isn't this how post order used to work? You just send a pre-printed form to the company and fill in the address and name? However, with computers automated scams are instant and could have a greater scale. I.e. instead of having some random person have a delivery pizza, you could order 1000 pizzas in 1000 towns.

Sometime people pretend that it doesn’t make sense. Had a real-estate say offers have to be a signed contract I say it needs a expiry period so people don’t come back in a month and demand the contract is followed. He kept doubling down on “I don’t understand the problem”

I believe the user id actually was the email address when they started out.

typiskt danskt att skicka massa knullsaker

I worked with a team that owned a service that resizes images. An engineer was assigned a task to add support for auto rotating images. His solution involved saving the image to a file and then using a library to handle the rotation. He used a hardcoded value for the file name. In a local environment where requests are sparse this looked fine to him and other engineers on the team missed it in code reviews. It wasn't until it went out to prod that he realized the error in this. Users started seeing other users' images because the file's content was constantly being overwritten.

When you test features like this or caching a response with a JWT it can be very easy to default to the happy path or ignore the impact of a large volume of concurrent users.

Years ago I added varnish in front of a website to cache image requests, not realizing that if the response included 'set-cookie' that was also cached.

We immediately started getting reports of random products appearing in our customers' shopping carts, as people's sessions got merged with random strangers.

I expect something exactly like this happened. I had a similar bug long time ago. Apache was somehow incorrectly caching the request and the session cookie in the request ended up in a cache. But it happened only about 1/10,000th of the time so it was impossible to figure out the root cause.

However, one common source for this kind of bugs is to ”cache any URL ending .pdf as a static file” and then you are in fact serving logged in PDFs like customer invoices that come with the session cookie.

I think CloudFlare used to come with a default rule to treat .pdf as a static content. The responses were cached when you hit their ”cache the good stuff” checkbox.

I doubt that Klarna, a bank, have OSI layer 7 proxies in the cloud, with TLS termination in their CDN solution, on AWS. I would assume this traffic is outside of that. But then again, I know they wasted 25M+ Euros on a garbage NodeJS platform. They also created an own cloud once. Yes, it is in the trash bin.

I can 100% see this being the cause if this comes out as the root.

But... API's really shouldn't be cached? At least not at the CDN level. The risk of serving up stale dashboard data alone makes users go ????... and we definitely don't want - not even mentioning the problem here, that's crazy.

This reminds me -

A couple of years back, I was making https://lifeboxhq.com which involved users uploading quite a bit of content. I was happily testing security with some url resource enumeration and for some reason, I could non-deterministically access user uploads via url, even on accounts I didn't own. I spent several days looking at my Flask code, javascript, etc. to debug....

I knew it wasn't my code, but I was getting more and more frustrated, then I remembered I set up Cloudflare....

Remember to exclude certain routes from Cloudflare if you want to avoid arbitrary user content from being cached without authentication.

I introduced a similar bug into one of my products in the past (Be honest, who hasn't?). But I'm surprised here because Klarna is a quite mature product and something like this shouldn't really happen at that stage.

I remember something similar when there was a load balancing issue with some website where it would randomly assigning a user with someone else's account.

To get around this, one could include the request IP address in the JWT and required a refresh token to be sent when the user's IP switches.

Did you compensate the victim of your personal and corporate negligence?

And this is both maddening AND make the problem worse (from the CEO):

"We are truly sorry for any inconvenience..."

A lifetime ago I was writing code for airline data processing. The specs are very clear about what the valid representation of every field was (less so about what they meant, but...).

So we generated our parser to fail if field ORG/1457 (made up) was not numeric max 8 digits. Or missing where mandatory.

Even if we never touched the data in that field.

Turns out that no-one else used the spec that way. No two were the same, so we had to basically implement two layers of parsing. One to put the data in a common parse tree, and the other to per-sending-mainframe interpret the data as how the sender had implemented.

We assumed that the mainframe would never send illformed data, and indeed that-could-never-happen. But they differed in what they thought was well formed.

Klarna uses erlang and erlang enforces exhaustive conditionals and pattern matching so the error / unsupported case is always handled.

I like defensive programming. Even though I think the state is unreachable, it feels nice to add a panic assert just in case.

If it is due to cache, then extra check like you described probably would not help.

Most people I met who do double checks would simply return "not loggen in" and issue a WARN deep within the other 200 WARNs-per-second. That is IMHO a very bad usage of double checks. It gives a false sense of security and masks the deeper problem until it's too late.

However, if you make the assertion fail loud, then it provides an additional security layer and should be used as often as makes sense.

This is very good practice as far as I'm concerned. Functions should treat their arguments as potentially hostile input.

I think there's merit in objecting to "that will never happen" checks in some cases (though, to be clear, I'm not saying the people objecting to your code are thinking about the same thing I am).

Specifically, if you have data that is loaded from some other source, your extra safety check might be checking data that's loaded from the same source, in a way where if something did go wrong, it went wrong in both places you're checking.

In this case, it seems pretty unlikely that Klarna's bug was that they ran "SELECT * FROM users WHERE Username = 'joeuser'" and they got back a row where Username != 'joeuser'. I don't think there's a recorded case of that ever happening with databases.

However, it seems much more likely that Klarna's bug was in HTTP caching or something, that results were returned for the wrong user. Then there's no opportunity to see databaseUser.Username != form.Username: that check would have indicated that things are correct, but the username being passed into this code was wrong in the first place. That sort of problem definitely happens in the wild - see the "Kenneth" story elsewhere in these comments, or off the top of my head https://blog.zulip.com/2021/03/20/zulip-cloud-security-incid... from two months ago.

And if it is, somehow, a database bug, why do you trust the database at that point? What if the database returns part of one row and part of another? What if it returns the username you sent in because of some optimization to avoid copying data, but thanks to a bug (or a cosmic ray) it reads in the rest of the data from an unrelated row? In the unlikely but not totally impossible case that you need to protect yourself against this, validating the username isn't enough; you'd better sign the entire database row and validate the signature before trying to use any of the data that's been returned. (And come up with some reason why you trust your own app code more than the database.)

The problem with such "silly assertions" is that they make you feel like you've added test coverage, when the thing you're testing is something like a database that is extensively tested by its vendor and by everyone else using the database, and there are other seams in your code which are much more likely to break. Meanwhile, they make the code longer and harder to read, which prevents readers of the code from easily identifying what those seams are.

(And by slowing down the API endpoint that talks to the database, it motivates other developers to try to put some caching in front of that endpoint, which may actually cause this sort of problem!)

I agree, and I've also been called out for doing "stupid" defensive assertions. It's almost certainly not a code-level issue this time though. This whole thing reeks of infrastructure/caching issues.

it's fine to make the check but I hope you don't sweep it under the rug with an early out without at least logging the occurrence

Happened to Steam in 2015. In their case it was a caching issue.

https://old.reddit.com/r/Steam/comments/3y7lxm/when_i_go_to_...

https://www.forbes.com/sites/insertcoin/2015/12/25/steam-is-...

In their statement they deny accessing bank details:

> The bug led to random user data being exposed to the wrong user when accessing our user interfaces. It is important to note that the access to data has been entirely random and not showing any data containing card or bank details (obfuscated data was visible). This means that it has been impossible to access a specific user’s data.

This is not the experience of the user in the OP: https://twitter.com/esraefe/status/1397843949985931265

> affected up to 0.1%, approximately 90 000, of our users

Does this mean the bug affected .1% of accounts or that only .1% logged in during the 31 minute window when the bug was present?

> It’s concluded that a human error caused the bug

I would not want to be that "human" atm

They mentioned human error. I could feel bad for the human who error-ed, but I wonder what kind of human error could have this huge impact.

It could be something to do with cache configuration.

This also happened to GitHub recently, although limited. https://github.blog/2021-03-18-how-we-found-and-fixed-a-rare...

I remember when this happened to Apple with iTunes Connect (where developers submit apps for the App Store) back in the day:

https://techcrunch.com/2015/01/29/itunes-connect-issue-loggi...

Also to Italian Social Security agency last year (anyone surprised the site was built and maintained by a big ITC company?)

It also happened to Chase (!!) a few years back.

I can understand avoiding a company due to a bad experience but that sounds like a rather general and rather restrictive conclusion. Did you mean bookeeping specifically, or payment handler, as they are somewhat different things?

For small businesses using a payment processor removes a massive barrier to market entry. Many small business hire real world external accountants to do their bookkeeping, so "avoiding actual work", would you avoid them as well? I do some work with the accounting & invoicing teams in our corporation and there is a LOT to take into account that would cripple a startup with only a handful of employees.

Bigger companies use services like Klarna not because they can't (often they have other payment methods as well and do their own bookkeeping), it's because customers like to use them and failing to use something like Klarna means their customers will shop elsewhere.

In Norway, we call this class of error "a Kenneth", after everyone who logged in to see their tax return in 2012 received the tax return of a guy named Kenneth. The culprit was allegedly a misconfigured load balancer.

Way to make me run away from them fast.

They incentivize e-tailers by offering higher conversion rates(later) as well as taking the hit for fraudulent payments (often with regular CC billing an e-tailer can be liable for repayments) in exchange for a slightly higher percentage.

Once someone comes to their checkout they hide or at least make the direct payment options well hidden so that by default people buy by taking credit with them.

This credit often comes with shorter than industry standard payment terms so people end up missing payment and being handed over to their in-house collection agency that starts collecting overdue fees.

It's considered digitalized loansharking by many for a good reason.

Ironically it seems that for many smaller e-tailers using Klarna as the payment option seems to heighten the trust of customers so they're more likely to buy (my guess is that we've all been told or told people historically not to enter CC details on random sites and even with stuff like 3D-secure these days everyone is wary)

Not sure where you are located, but in Sweden, Klarna at the start (if I remember it correctly) only needed your 'personnummer'(social security number) to process payments.

Now I think they manage to track your devices so I only have to enter my postal code, and then I just click purchase, and it's all done.

They used to use really weird/dark patterns, to make you forget to pay and then pay huge fees to Klarna.

Nowadays as I've configured Klarna, it just subtracts the amount from my bank account, hassle free, and I don't have to do a bunch of reserach wether or not the website is credible.

Somewhat like Paypal, but smooother.

Klarna seems to be super popular with e-commerce sites, my guess is that there's some kind of financial incentive to the hosting site, when compared to other payment options.

As to why it's popular with consumers looking at https://www.klarna.com/uk/smoooth/ , seems like they're offering months of interest free credit and also the implication is that using Klarna doesn't affect credit score.

It'd be interesting to know how their credit risk setup works.

In Sweden you can use them to buy with an invoice which is a lot quicker than entering your credit card. That is probably the main selling point.

Sellers get paid immediately and they take care of making sure the customer pays.

With Klarna you just need to type some information most people know by heart (10 digit ID number, f.ex.) before the order is confirmed. This is convenient if one wants to buy something quickly from a mobile phone. The address will oftenalso be prefilled. A credit card number is much more cumbersome to type on a small device, and the address needs to be typed in separately.

Some banks used to require people to log into their banks to temporarily unlock their card for internet shopping, or, nowadays, one also needs to authenticate the purchase with the bank. That adds extra friction.

With Klarna one does not need to pay until 14 days after the goods are shipped. Credit cards are even better, but most people tend to just have a debit card. With Klarna they don't need to worry about spending too much money from the account and having some other payment bounce later on.

I personally stopped using them after I fell for one of their dark patterns and bought something on credit, which incurred an extra fee. Legally I was entitled to cancel the credit purchase, pay the full amount and avoid the fee; but I was still annoyed.

They usually offer deferred payment via invoice, removing the need to input CC details at the time of purchase. I've used that a couple of times, just because I wanted to move on to other tasks.

(Not claiming it's a killer feature, but it's a feature.)

They were also doing short-term loans [ https://www.bbc.com/news/business-56343942 ], which were for a while being pushed quite heavily in some internet community things I'm a part of.

Also, I figure they must be paying a lot of money to be the default payment provider on so many services.

For me, asking for my bank login details is...ridiculous - it'll be interesting to see if it is still following the same tactics in a few years.

Same experience here. I assume it works better in Sweden, but I have no idea why someone with customers outside Sweden would want to use this.

One e-shop I use regularly switched to Klarna and the whole checkout experience got much worse. Simple forms replaced by broken interactive ones, etc. It's still not better than the old UX, even after multiple iterations. I'm more reluctant to enter CC info than before, for what that's worth.

I think the main selling point is being able to buy clothes and return the ones that don't fit without having to pay for the lot first, and get a refund later.

The same can be applied to a credit card though so it's not a strong argument

You can get an invoice that you will pay later. Thus, you don't need to look for your credit card at the time of the purchase.

You can choose to pay at a later date

You can choose to split the payment into installments

When I buy things (Sweden) it’s basically one-click checkout with just the e-ID signing to pay directly from my account, not via card. Definitely convenient.

Happened to Valve too, Christmas 2015: https://arstechnica.com/gaming/2015/12/valve-explains-ddos-i...

Sometimes I see my own mails before logging in for a short while in Outlook web app. They have some issues.

Yup, when you get it wrong you get to meet interesting people from the compliance department. The "enable cache" button in the load balancers should come with alot of warnings.

Hear hear, I used Klarna (not by choice) and it surprised me they would feign being me in interactions with my bank. Exactly the type of behavior techies are trying to teach the older generations to NOT fall for.

With this, we know that Klarna's software quality is papier-mâché level. I am happy I refused to let Klarna have my account authorization.

There have been some weird legal cases in Sweden where businesses and scammers have been freed after having signed in using other people's "BankID" to change retirement savings around or send cash.

Its the ID method I use for credits, pharmacies, health care, taxes, but was apparently not an ID so it's not id-hijacking.

Klarna has man in the middled my bank account before and performed a purchase and I've boycotting any company having them as the only payment option since.

OH, now I also remember Klarna adding credit in my name since they only needed my tax registered adress. I lived in a dorm so someone just used our public information to take out credits to order sneakers and could break into the crappy entry mailbox.

Yeah I once had to make a ~20k transfer with Klarna and was shocked to see that they essentially hijacked my credentials. I only went through with it because there is additional 2FA (on my bank) so they wouldn't have been able to repeat it. But still a super shady practice. I was sweating for days until I got a confirmation that the transfer went through successfully. 1/5 experience.

I have the same sketchy feeling about Sofortüberweisung/Klarna. If they want to make transactions on my behalf, why should I give them full access to my account?

Most banks have a paragraph in their contracts/ToS forbidding sharing the account with third parties, but they are rarely enforcing it. Still, they could close the account due to contract/ToS violation.

I understand that Sofort was allowed to continue despite using the user's bank credentials because disallowing them would be anticompetitive.[0] I have no idea how that could justify such an insecure practice, but there you have it.

[0] https://knowledge.fintecsystems.com/en/blog/the-history-of-o... , under "Legal Action by Giropay"

Have been using SÜ for years until I learned that they not just facilitate the transfer but abuse their role to dump bank transfer data worth several months. I don't use that service anymore.

Sofortüberweisung specifically got caught looking at 30 days of transaction data.

> how banks can allow this

A court decided that blocking this "business model" would be anticompetitive.

Can you explain more about the credentials and online banking?

I've used (and integrated with) Klarna in the UK and from what I've seen it's only really a payment method with merchants who you pay back by card later.

Klarna is actually its own bank these days so that doesn't really happen anymore. I think however many other payment providers operate this way still which is ridiculous.

Then again, PSD2 API roll-out has been very ???

What could a competitively convenient way to do this better look like?

I cancel every online order if I find out that it is handled by PayPal, Klarna, Mollie or other data collecting entities.

The situation in Europe is so bad that you are sometimes tricked into a prepaid order only to find out that the invoice comes from one of those.

The appropriate penalty is immediate cancellation and multiple GDPR requests.

Yes the chance of that is almost zero. Either the due is the actual users value (only profile name is changed) or this is some kind of test data being exposed.

We can only speculate, but what baffles me is that it happens for something so private, and for a company that is so rich. Do they not audit their code? Do they not risk assess these things? "Ah, storing user credentials in thread local storage, that sounds sane and bug-proof" said no auditor, ever.

IIRC, Klarna is mostly written in Erlang, Scala and some parts in Clojure.

If someone should be aware of thread-local storage and its implication it ought to be them.

Is your email adress firstname@something.etc?

I've seen a lot of people not get their emails and wondering if they parse lastname.firstname@something.etc wrong

A recruiter contacted me aswell and I asked about their salary. They pay 50k euro for juniors in berlin with afaik no stock vesting. How they even manage to get qualified personnel is beyond me, I would expect much more for a fintech with over 3B evaluation

> getting 'random' records that correspond to a given ID but that's for the wrong table...

That's why I use GUID instead of integers. If you get a result, it was the right column.

1) Caching: a cache is used in front of the API for things like product listings, it uses a pattern match like /api/products/*, and caches routes which match. Someone accidentally configures it to cache /api/*, and thus login responses from /api/session return another recent user session, potentially including the cookie such that subsequent requests are authenticated as that user.

2) Mentioned elsewhere in this thread, a variable with global scope within an application server. This is very possible in node.js, which uses a long-running single thread - if you have a function like handleRequest(), you might inadvertently write to a global variable outside it, and that variable will persist across requests from different users. I've seen this exact bug in a PR - luckily we caught it before production, but if it had slipped through code review and integration tests and actually shipped, the result would have been exactly like the one in the tweet.

From a quick glimpse on twitter, people couldn't make changes to any of the accounts they were seeing.

This points in the direction of this being a caching bug; you request your homepage, and get the homepage of whichever user was placed in the cache last.

Most of the time in these situations it's not an application-code issue (per-se), as much as a "shared global state" issue.

It's not a web system but Mac OS messed it up once: https://objective-see.com/blog/blog_0x24.html

Caching could be an issue, if they added a cache for a microservice call of /get/user?id=$USER and ignored the id parameter, /get/user?id=ipsin fetches data for the user ipsin, the system sees the next call /get/user?id=bellyfullofbac and thinks, "Wait, I have the results of /get/user in cache" and returns the data for ipsin again...

How do you envision the static variables thing? I've seen the cache thing myself in real life but not the other.

they shut off the whole app, and kicked off who was logged in. Fair approach until they figure out how to sort it.

Probably a push to prod of something of something that worked on the developers machine, Klarna is at the size where any fault like this would be seen by thousands within any reasonable reaction time.

According to the article they shut down all logins in the app. Unsure if this means you can still use it you are already signed in or not

As I read it, they did shut down as soon as they knew.

That thread got spam flagged or something and is no longer visible, but has a lot more comments and discussion.

the linked thread was posted after this one.

Why did this one disappear from the front page so fast?

tangential thought, but related: I am, in general, a proponent of nuclear energy as a green alternative to whatever the hell we are doing today. But when I see such stories that humans manage to fuck up simple payment processing apps, still make errors while maintaining bridges, still manage to do hugely negligent screw-ups (most likely corrupt) in *cable cars maintenance*, I immediately think that it is imminent, that something will go wrong with such complex thing as a nuclear reactor and the price there is much bigger.

Oh boy this brought back memories for me.

I thought that IQ test was screening test, pre-phone interview. But no, they had me redo it at the onsite interview too. The funny part was the onsite test had the exact same questions as pre-phone interview.

edit: typo

Yes, sadly a quite common part in too many recruitment processes here in Sweden.

They did it a year ago when I was applying there. I was so annoyed it almost made me cancel the interview. In the end I canceled, because they didn't allow working from home.

Doesn't almost everybody? I mean let's get real here, what's the IQ distribution at FAANG or any other competitive software engineering company?

There may not be an explicit "IQ" portion to the process, or a hard number, but they are absolutely filtering on intelligence. An uncomfortable aspect of our society that I'm both surprised and not surprised doesn't get talked about much.

When I applied to work for a bank in Canada back in the 80's I had to write a Wolfe-Spence Programming Aptitude Test (was basically an IQ test).

The hiring company would send your answer sheet and work sheets off to the company to analyze and provide a score.

Anyone else remember those?

Yep, took it just a month ago. Quite dumb honestly, not sure what it indicates. It was a bunch of weird pattern matching and guessing? Seemed easy, but got a rejection a week later.

They did that?

Although, I guess Google does IQ tests too in effect? But it's called "solve this puzzle" and "here's a riddle".

We are all mistakes that sometimes make humans.

yes

It's not an IQ test. It's just pattern recognition which is about 5% of the tasks you do in a real IQ test.

When I joined Klarna in 2011, the test was so easy that I joked I could score full marks on it even if I was hungover with no sleep. There was one question on the test that actually had 2 correct answers depending on what logic you applied. This was actually a real issue when recruiting, because there was a hard cut-off to make it into the engineering department, and several times I had to ask "what was their answer on question 12?"

It caused quite a bit of commotion at HR to change the official test scoring to 2 correct answers for that question.

Now the test is like a million times harder and your score at the end is between 0-10 and you have no idea how many questions you actually answered correctly. I would be very interested to know the "true" answers of these new tests to understand what kind of crazy logic you need to apply to get every question right. I'm almost certain it would take me longer to understand the answer than the time you have to do the test.

if they make it though alive ...

Out of curiosity, how is that enforcement usually done? I have usually just used some SQL database like MySQL/Postgres, and having application determine how to fetch data, so application has access to everything. I can see how this could be insecure due to some bug in application code fetching with wrong WHERE etc, how would one go about enforcing it on sql/database layer?

Would you have separate SQL credentials for each user, and configure SQL for each credential to have access to certain WHERE queries, or?

To simplify a use-case let's say I have "users" table and "tasks" table, where there's user_id in "tasks". Would I have separate sql credentials where they are configured in sql layer to have access to only rows where user_id corresponds to this certain credential? But even then how are credentials mapped to userId, as bug in application could easily cause retrieving false credentials?

Other way I can think of is to just have completely separate databases for each user, but let's in this case assume we must often do work with a mix of different users data.

How would any measures at storage layer prevent, for example, issues in caching?

In my experience very few have storage layer separation for customers data. It all logic in the application layer to control access.

Do you mean stuff like row-level security in the database tables?

Cached data in middle layers can get even the safest of row-level secured databases.

I agree in general that you need to enforce things at the storage layer.

If it's really a reverse proxy / Varnish / CDN / etc. misconfiguration issue like some others here suspect, then it could be totally random. The data of some unlucky person whos data happens to get requested when the cache times out will be cached and then sent to all others.

Reminds me of a colleague implementing "emailRecipients" as a field in a singleton service. The first online order got an order confirmation mail, and when a second online order came s/he also got their confirmation mail (the field just grew and grew...).

Could be random. I've seen this behaviour when enabling puma and using non thread-safe code. Just entirely depends on the timing of the requests.

I suppose that maybe comes down to your definition of what 'random' is.

You can't—at least in Sweden—remove much from Klarna.

Your marketing profile is tied in with their accounting system. The law requires them to store accounting data for at least 7 years, with no obligation to actually remove it once that time is up. Since the accounting laws supersede the GDPR: they can hoard data pretty effectively.

The Swedish 'Data Protection Authority' tried to launch (yet another) investigation for their shady practices, but Klarna strategically applied for bank status and now the reach and power of the data authority is cripplingly limited.

Let's Encrypt started in 2014 to address HTTP overuse.

In 2011, I (in-house corp app dev) was still stuck with HTTP services (behind a firewall, accessible only via VPN).

In 2014, public facing mobile apps using HTTP was prevalent enough to prompt name and shame campaigns. [1] My fuzzy memory suggests some banks were still using HTTP.

[1] https://arstechnica.com/information-technology/2014/08/new-w...

That only protects the user's password. The auth cookie will be sent in all subsequent requests in plain text.

EDIT: that's how firesheep (https://en.wikipedia.org/wiki/Firesheep) hijacked sessions for e.g.

Only for certain domains and in certain regions.

A lot of the web was still on http, including some banks.

Even Facebook was still primarliy http when Firesheep [1] came out in 2010.

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

Not sure why you are being downvoted but this is exactly correct. We had, as an industry, been so focused on PCI during this time and TLS was and continues to be the most important aspect of the protective technology. SSL/TLS had already made e-commerce viable in the 90s and its power was well known and being applied for the decade following. Being in 2011 without full ssl for authenticated access was quite bad behavior indeed. Maybe excusable for some low rent bulletin board, but perhaps that is what the commenter was operating. I have no clue.

We detached this subthread from https://news.ycombinator.com/item?id=27303744.

> You weren't born with an account.

A merchant I shopped at, and paid in full by card, opened an account for me and shared line item details with Klarna, apparently because they are using them as their payments processor in addition to an installment payment option.

I noticed this when I later did in fact "open" an (or rather, claim an existing) account with them.

Very disturbing, and the bad aftertaste has never fully gone away.

This comes across as "If you haven't read every word of all the terms of use, privacy policy, and any other legal documents of not only the initial company you interacted with, but of all their second party companies, and their services, and their services, until you've researched the entire chain of partners who could potentially have something to do with your transaction, then you are obviously complicit in everything all those companies chose to do and you have no grounds for complaint."

While you may be literally true, the reality of this economic situation is full of far more gray area than you allow for.

If this confrontational, extrermist position is intended to try and wake people up to all this, I fear your message is outweighed by your snark.

And if you don't care about that, then I've wasted as much of my breath as you have yours.

In Sweden there is a current cultural view that the only reason someone would not sign up for an account with any kind of banking service is because they are too old to navigate the registration process, in which case all they need is help going through it. Any other explanation for why someone does not have an account at X is perceived as perplexing or straight alien. Non-coffee drinkers will have an easier time culturally then those rejecting getting accounts at sites like klarna and swish.

I needed to buy things, because that is life, and the merchant only offered Klarna. You might want to reconsider your hostile rhetoric, it does not come across well.

It at least used to be very easy to accidentally sign up for Klarna, thinking you're just paying by card.

In principle I agree, but you can be tricked into using Klarna. However, in Europe you should be able to cancel the order without reasons.

We detached this subthread from https://news.ycombinator.com/item?id=27301463.

Whatsapp was fantastic when it started. Right up until it was bought by facebook.

Swedish is easy to translate with GT, here's a quick translation of the state news reporting,

"Users of the payment service Klarna's app testify about disruptions on Thursday. Anyone who logs in with a bank ID has in many cases been able to see other people's information, including payments and invoices.

- It is very serious and violates privacy, says David Bjurhede, one of many who noticed the disturbances.

Many who have logged in with a bank ID on Klarna's app have on Thursday morning been able to get to someone else's account, users tell SVT Nyheter.

David Bjurhede is one of those who noticed that it was possible to see another person's information in the app, including what purchases had been made and parts of the account number. - It is very serious and violates privacy and risk of fraud if you can find out user information so easily, he says.

Another user says that he discovered the error at 11 o'clock and that it was possible to take part of other people's information for about 20 minutes. - It was possible to see almost everything, parts of the card details and exactly what they had bought and what their finances look like at Klarna. It's a little scary. I have not been through it before and I think it should not happen, he says."

I don't think it's nice to make fun of beginners in our industry.

> quite low likelihood if the sampling is truly random...

If you're assuming their user base is 50/50 male/female, which for many apps is not a valid assumption.

If I remember how to do math correctly, 50/50 gives 5 random users all being female ~4%. And 80/20 split is closer to 40%.

I've seen something like this happen because of a race issue during login. Basically the developer(s) had refactored something and were not aware that a global variable was being captured by a closure used for auth.

This meant that whenever two users signed in at the exact same time, there was a non-negligible chance that they swapped accounts during the flow.

It was actually not that easy to spot in the code. Sometimes what looks really, really stupid on the surface may in fact have a complicated and not-so-stupid explanation, often involving multiple developers and modernizing legacy code.

If it is a race condition, it can be incredibly hard to find during test.

Even if it is a stupid mistake, like e.g. not marking session cookies as secure and private, it does not mean that all of the rest of the code is bonkers.

Whole implementation? It's probably the edge cache catching a cookie on the way out, a toggle box somewhere.

>agile, and start-up hipster culture

What does that even mean?