"The payment giant Klarna, which has 87 million customers globally, currently has major technical problems. Users of the company's app saw other customers' payments and personal information, before it was shut down completely.
The supervisory authority Finansinspektionen, FI, has asked Klarna to explain what happened."
I find the default Twitter response by the Klarna social media account really annoying. The issue is not a system disturbance. The issue is clearly in the whole implementation of the system itself, code which was written by developers and where something really stupid has been implemented and where security was not taken into account at all because an issue like this could have been prevented at so many layers and yet it happened.
With all respect, I don't disagree with your assumption about a silly cache somewhere, but that is sort of my point, if such a severe privacy and security vulnerability can be introduced by a single toggle box somewhere then the architecture of their platform is hugely lacking IMHO. This is not a cat photo sharing platform but a fin-tech business and there should be more layers to security than a single toggle box.
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.
Not always. Like if you initialize middleware by using a "lambda" (closure), and you from within that closure creates a new closure.
It means that you need to be aware of the context the outer closure is used in. If it is only instantiated once during initialization, it's free variables are in essence "hidden" global variables. Not easy to spot.
I've had this happen, although not on a scale as this, when implementing caching and disregarding authentication as a parameter that varies the cache...
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.
Huh, from the headline I was thinking it was intentional! Nothing but marketing fluff in the newsfeed yet, still waiting on an article that's not walled in Swedish(?).
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."
Let's hope not. They're deliberately trying to get people to take on debt rather than just do card payments, and even simple things like buying a book through a web site requires declining several offers for paying with credit.
Unfortunately, they're huge, and I doubt the Swedish authorities will do more than give them a fine and a slap on the wrist.
Finland doesn't have credit score system, so there's no reason to not pay not pay the credit card bill immediately. There is certain push towards credit cards, though. As far as I remember my bank would charge a yearly fee for debit card, but credit card is free for me.
For what it's worth, I have paid for nearly everything I possibly could with credit cards for decades, and I haven't paid a cent in credit card finance charges in at least 15 years (since my fiancee straightened me out and helped me see that I was being dumb about debt). I have them set to auto-pay the entire balance every pay period.
I use them because consumer protections with other methods aren't as good here in the States. Paying with a credit card, if I have an issue with a vendor, after a good faith effort on my part to resolve the issue, I can just ask the credit card company to deal with it. (I don't abuse this, but I don't doubt there are people who do.)
There are better and worse credit card companies for this. American Express has great customer service but they aren't accepted in as many places.
Debit card payments are not debt - they're effectively the same as a direct transfer from the user's bank account.
I'm very conflicted about Klarna - on the one hand they do present an easy and (usually) safe way to handle transactions with small retailers to whom I don't necessarily want to share my payment details.
But on the other hand, they use a variety of dark patterns to try to get you to pay:
1. on credit
2. by signing-up for their credit-card
One unfortunate part of their earlier history, was that when you promised to pay with Klarna on a website, and was told you'd receive the invoice, there was a (perceived?) tendency for that invoice to never be sent due to an 'oversight'. When this happens in Sweden, the buyer gets a reminder a few days after the due-date, with a pretty large extra amount to pay.
There were quite a few stories about this in the press at various times [0], and I know quite a few people from Klarna and would tease them about it - which they always strenuously denied - but then it happened to me.
In any case, finding out how this happened is going to be interesting.
DeepL translation:
"Lots of complaints against Klarna invoices.
Klarna, the high-profile IT company, is being criticised by a host of customers. Many say they receive invoices with reminder fees and collection demands directly, without having been reached by an original invoice. The Swedish Consumer Agency is critical of Klarna's invoicing methods for several reasons and is currently investigating whether the company is behaving legally."
>They're deliberately trying to get people to take on debt rather than just do card payments
So what? It's 0% interest. It's incredibly helpful to have easy-access financing to split purchases across a few months.
>even simple things like buying a book through a web site requires declining several offers for paying with credit.
This sounds so specific it seems like you're taking a bad experience with one website and pretending all websites are like this. Most e-commerce sites I've used in the past year offer Klarna or some similar service and all of them have been implemented as just another option in a set of radio buttons.
Debt is slavery and so on. Let's not get too hung up on the fact that I dislike it.
> Most e-commerce sites I've used in the past year offer Klarna or some similar service and all of them have been implemented as just another option in a set of radio buttons.
Radio buttons is fine. It's the defaults and "are you sure you don't want to pay with credit?" questions I'm bugged out about. I don't have an issue with them offering it as an option. I've seen it with multiple websites using Klarna for payment handling.
I agree, but just to clarify: inability to pay one's debts has historically been one of the primary ways into forced labour with unfavourable conditions. A bit away from slavery still, but not a completely out of the air connection.
You missed the point. It was a deliberate simplification (hence a simplification of a biblical quote and the addition of "and so on") intended to steer the focus away from my personal opinion about debt, and towards the second point, i.e. dark patterns in order to get people to pay with credit rather than with a debit card.
> It's incredibly helpful to have easy-access financing to split purchases across a few months.
I don't know, it seems like a failure at adulting to have to do that for small to medium sized purchases. If you need the feature, you probably should not have it available. Maybe this is my German attitude about money - basically, only take on debt for investments, a notable example being housing.
> So what? It's 0% interest. It's incredibly helpful to have easy-access financing to split purchases across a few months.
Unfortunately, this often isn't the case of people who are worse off, not good at managing their finances, and often overwhelmed by bureaucracy.
They fall behind on payments, and then get taken to the cleaners on fees, deferred interest etc., often paying several times the actual price of the product. I've seen this happen (with different but similar services).
Less savvy people being sold stuff they can't afford on credit has been such a problem that some countries have made it illegal to extend credit to someone who can't afford it, which is obviously extremely hard to enforce.
This is hard to grasp for many here, because HN readers tend to be well above average intelligence. Try to think in terms of "imagine how dumb the average person is, and now realize half the people are dumber than that". Now add mental or physical health issues into the game.
MS Exchange outlook web interface sometimes showed me completely unrelated mailbox content upon login: folders, list of messages, read status, subjects, etc. Trying to open email never worked though and the whole problem goes away after page refresh.
I like how when the session expires and you login again you get redirected to the random resource your browser requested when it just expired. So instead of the mail view you sometimes get the new mail jingle or some minified js. Makes me feel better about my own imperfect software
Their German counterpart, Sofortüberweisung, didn't properly blacklist test credentials given out by banks e.g. to developers in the beginning, so people could simply use those and pay for goods and services with fake accounts.
For me there are so many red flags with all these services, as they basically "steal" your credentials to log into your online banking. And while they claim that they only use the credentials to make transfers they could as well look at all my other account data. I really wonder how such a scheme can be legal and how banks can allow this, as they normally tell people to never give their credentials to anyone. The situation of course recently improved with the mandated 2FA for logins and transfers, but still there are so many attack vectors in this model that it boggles my mind how it can still exist.
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.
In Denmark, you're forced to use the state-run "NemID" for credit card payments, making for some weird situations where you authenticate with NemID inside iframes on shady URLs.
The same NemID is also used to file your taxes, look at all your health info, get married, everything basically.
Credit card payments are much lower security level, and they're basically forcing sharing credentials amongst all the sites you pay on.
2FA is already mandatory by the PSD2 directive of the EU. I use my debit card as the second factor to access my bank account here in Germany via ChipTAN
> 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.
As far as I know most, if not all, of these scams have been perpetrated against the elderly. All operations (authentication, signing) can be initiated remotely with just a personal ID number, so the typical scam meant calling up someone and claiming that "an authentication must be performed", and simultanously initiating a bank login session. If you can keep the victim on the phone and using the BankID app when you tell them, you could basically login and empty their bank accounts. This has been largely fixed using QR codes to initiate login requests for major internet banks (which means you have to be in front of the same screen now) and other clever workarounds. But it has also always been a fact that there will be a description saying what you are signing, in the app, so being careful you could easily avoid being scammed.
I think its largely a great asset (BankID) but its never gonna be 100% tamper-proof without being seriously neutered.
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.
Is that true for all European banks though? I think they all need to have an API available at this point, but is Klarna using that in every instance (instead of their legacy creepy MITM scheme) already?
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.
In Sweden most people have an electronic way to identify themselves to their bank (BankID) and it is used by many services to verify your identity.
It's extremely useful for any ID verification, but Klarna asks you to verify your identity towards them but when you open the app they have instead sent a request to identify with your bank, using your credentials.
Klarna provides many different financial services.
They provide "pay by bank account" (which involves the mentioned MITMing of users' online banking accounts, unless Klarna is integrated with your bank via OAuth/PSD2, which is still not ubiquitous), but also installment payments/factoring and others.
Surprisingly, there are already integrations in my home country; I took a look at tink [1] some time ago (no affiliation whatsoever) and they look legit. I'm sure there are more SaaS like them.
You can generically solve the problem of Alice giving David access to Bob's service on her behalf without giving Alice's credentials for Bob's service to David using stuff like OAuth2, this is already how lots of things work today.
In OAuth2 David only ends up with some token showing Alice authorised David to use this service on her behalf. Bob can tell David and Alice apart, and choose to restrict what David can do appropriately.
If Bob is particularly tired of this nonsense, and his customers like Alice keep giving David their credentials and then are surprised that doing so means Bob can't tell Alice and David apart, WebAuthn reifies it so that most users in Alice's position can now see where the problem is. When David tells Alice he needs her Yubikey to access Bob's service, it should occur to Alice that giving the Yubikey to David isn't a good idea because then she won't have it any more. Good.
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 looked through the terms of use and the privacy policy for Mollie and I don't think they are selling data. Do you have different information then I have?
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.
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.
That sounds pretty bad! I always thought the login flow was super sketchy, but wasn't aware of this part — has this been covered/analyzed somewhere or is it evident from their terms or something?
They claim they need to do this to make sure there is sufficient money in the account, even with transactions that might not be reflected in the balance, and they also check for other "Sofortüberweisungen" to detect fraud.
Makes sense in a way but still quite shady. If there wasn't enough money in my account, or other transfers pending would my bank even allow their transfer?
Lots of times when I’ve been buying things in e-shops I’ve been offered to pay using Klarna as a payment broker.
But doing so has always been more confusing for me compared to “regular” payments with a credit card anywhere else, and has on overall been a negative experience for me.
I really don’t understand why anyone would prefer to use them at all.
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.
And they don't notify you when it's available for payment, or when it's about to expire. So if you order something, and it for some reason takes a few weeks/months before they ship it and it becomes available for payment, you'll end up with a reminder fee with no warning.
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
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.)
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.
Klarna is very easy to use. They take a large part of the risk. The seller typically sells the purchases to them.
It may be different in different countries but the thing with the interest free credit is that once you don't pay on time it is converted into a revolving credit with high interest rate and something like a 60 months payment plan.
Klarna have also historically made up own names for fees to circumvent regulations for regulated fees. They were among the first to remove days of grace and among the first to use a fixed number of days from purchase to due date.
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)
Klarna is really shady. It encourages a 'buy now, pay later' mentality, which may be convenient right there and then, but it creates an unhealthy style of shopping:
It's really disturbing to see Klarna as a payment option in many Dutch online shops. These always already have iDEAL (which the vast majority of customers use), a convenient way of doing an electronic bank transfer; and most shops support credit cards too.
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.
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.
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.
> asking for my bank login details is...ridiculous
Is there more information on this? Are they doing the same thing Plaid does in the US? That is, literally asking for user credentials to internet banking instead of using the banks' proper APIs?
I don't know about current Klarna, but they took over Sofortüberweisung, which has been doing exactly that since 2004. Avoided them like the plague ever since.
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.
If you rely on your application layer to enforce data privacy instead of enforcing it in your storage layer its just a matter of time until you have an issue like this.
It says a lot about the security of their api and development culture that they are even struggling with something like this. This should be caught in the first architecture review session.
And how can one enforce it on a storage layer? There must be something in the application that determines user identity, which either threading, flawed logic, bug or caching (most likely) can mess up. In which case storage layer gets this identity information from application layer.
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.
So I think the best place to start is looking into row-level security in Postgres. Its a familiar place to start and gives a high return. Row level security can be used to implement the user / tasks use case you described.
I suspect this might be request threading/confusion[0] issue similar to the one GitHub experienced a while back. This would explain why seemingly random user data is being returned.
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.
I worked in a project over 10 years ago where something very similar happened!
We had built and authentication service that, among other things, was used by a SyncML service that was used back in the day of feature phones to syncs contacts etc. You can imagine that getting someone else's contacts on your phone isn't exactly ideal. This was how we came to know about the problem, from customers getting other customers data!
The error was caused by a CDN switch. Our instructions to the the CDN team responsible for the switch was "Make sure the CDN honors our cache headers, if our HTTP responses say something can be cached do so, if they say that the response should not be cached then don't". We were in at least three meetings where we repeated this mantra.
I believe that the CDN team thought that they had setup the CDN correctly but they had missed an edge case. The CDN was in fact setup to cache even uncacheable responses, and served those, _only_ when it could not reach our servers.
So if there was a traffic spike and the CDN determined that our authentication servers were unreachable it would fall back to serving data that should never have been cached in the first place! Happily returning tokens to random users that had authenticated just before the traffic spike...
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.
Happened for the danish tax authority about 10 years ago as well. Although I think the issue for them was that the unique login token was based on a timestamp that several users happened to share during very busy peaks.
Klarna wants to be Facebook of payment. When I buy and pay with Klarna, they get the list of items and on Klarna's app and homepage I see pictures of whatever it is I bought.
I'm not sure what to think about this. My first thought is "Is this really legal?".
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.
Whats Klarna’s argument for the data in a customer’s marketing profile being necessary for accounting purposes? You can’t just store data in your accounting system and wipe your hands of GDPR.
That's what the investigation aimed to find out before it was cut short. Klarna's general reasoning has been (A) 'because', and (B) 'because it's all in the same system and we have no obligations or confidence in thinning it'.
Any request for data or information regarding their architecture is rejected on the grounds of 'trade secrets'.
Hmm, that's strange. I did some contract work for Klarna about a year ago and had to go through mandatory on-site training and a big chunk of that was with their legal team about data protection, GDPR, about storing the least amount possible etc. It sounded like they treat it very seriously, so this is surprising to me.
I do know there are various legal requirements to retain certain data for some time (PSD2 for example must be stored for 13 months, I believe), but outside of that, it sounded to me like they tried very hard not to store anything for longer than necessary or without user consent.
I mean, doesn't mean its true, just the impression I got from the training.
You can forbid Klarna sharing the accounting data with anyone. I doubt there is a legal sharing permission overriding GDPR for accounting data aside from tax authorities.
That's correct, but the data still stays with Klarna. I interpreted the OP as wanting to remove the data Klarna stores, or remove the 'account' pages. Neither of these are completely possible.
I believe you that Klarna are shady about how they manage data, however, my understanding was that they got a banking license because they want to fund themselves via brokered deposits? A banking license means that they can get money from anyone in the EU and it will be insured up to €100,000. Without this, almost no one would want to deposit with them.
If you have other information about other reasons they might have become a bank, I would be genuinely interested in hearing them.
I was not trying to make a joke about the beginner devs. The list of choices a novice developer needs to make is reflective of our industry (why would there be so many choices). It is easy to make an error and bring the whole system down which in turn is the joke about "senior" people who instead of reducing complexity - increase it, and make it fragile.
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...).
Singletons are fine and useful in many situations. You just have to understand what singletons entail, and design them correctly. If his singleton had a "SendEmail" function that accepted an Email object with To, From, Subject, Body, etc. fields, it wouldn't have been an issue.
I strongly disagree. Singletons are most of the time a code smell. They hide dependencies, make testing hard, and enforce tight coupling.
Singletons are easy to understand, as long as they contain of one simple class. But after a few iterations of development, they tend to "capture" a lot of dependencies, which practically become singletons too. A lot of mistakes happen. And most of the time, there was no good reason to create a singleton in the first place.
I'm of the opinion that singletons are only useful if both of the following requirements hold:
1. They MUST NOT allow more than one instance. "I don't think anyone will ever need more than one" isn't enough. Just create only one instance then. Only enforce single instance if there is a requirement for it. For example, a logger is a bad singleton because you could conceivably want more than one instance. Something that requires exclusive access to some hardware may be a good candidate though.
2. The instance must be globally accessible. Many things don't need to be globally accessible though.
So unless you need a global enforced-single-instance of something, which in my ~20 years of programming is rarely needed, a singleton is a bad choice. In my experience, many times someone wanted only one instance, some time later it turns out that actually multiple instances would be useful after all (separate loggers for separate types of logs for example).
In most cases where singletons are used, a simple global would have sufficed. If you only want one instance, then create only one instance. If you need lifecycle management, then do something for that.
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.
Will be interesting to see what the problem is here. From what I have seen in real life my top guesses are. Some dependency on static variables in code. Reversed proxy with incorrect cache rules that ignores headers or some parameter.
Store user in static variable during processing data, then forget to clear the variable when you are done, so for the next request it still has access to the old data?
In C# for instance. If you mark a field static it is the same for all instances of a class (if you don't mark the code as thread static). So if you have static User field that changes on logon it will change for everyone. I have seen this but typically more complicated versions of it.
516 comments
[ 18.8 ms ] story [ 1154 ms ] threadThe supervisory authority Finansinspektionen, FI, has asked Klarna to explain what happened."
A future, fascinating post-mortem I hope!
https://old.reddit.com/r/Steam/comments/3y7lxm/when_i_go_to_...
https://www.forbes.com/sites/insertcoin/2015/12/25/steam-is-...
https://techcrunch.com/2015/01/29/itunes-connect-issue-loggi...
The session layer should confirm and only accept that the other SSL-endpoint is an authenticated app. The app should do this as well.
If a toggle box exists that can cause this, I'd wonder how much of else of the implementation is worth saving.
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.
Not always. Like if you initialize middleware by using a "lambda" (closure), and you from within that closure creates a new closure.
It means that you need to be aware of the context the outer closure is used in. If it is only instantiated once during initialization, it's free variables are in essence "hidden" global variables. Not easy to spot.
"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."
Unfortunately, they're huge, and I doubt the Swedish authorities will do more than give them a fine and a slap on the wrist.
Here in Finland, It's not uncommon to have no debt apart from the mortage on one's home.
I use them because consumer protections with other methods aren't as good here in the States. Paying with a credit card, if I have an issue with a vendor, after a good faith effort on my part to resolve the issue, I can just ask the credit card company to deal with it. (I don't abuse this, but I don't doubt there are people who do.)
There are better and worse credit card companies for this. American Express has great customer service but they aren't accepted in as many places.
Debit card payments are not debt - they're effectively the same as a direct transfer from the user's bank account.
I'm very conflicted about Klarna - on the one hand they do present an easy and (usually) safe way to handle transactions with small retailers to whom I don't necessarily want to share my payment details.
But on the other hand, they use a variety of dark patterns to try to get you to pay: 1. on credit 2. by signing-up for their credit-card
One unfortunate part of their earlier history, was that when you promised to pay with Klarna on a website, and was told you'd receive the invoice, there was a (perceived?) tendency for that invoice to never be sent due to an 'oversight'. When this happens in Sweden, the buyer gets a reminder a few days after the due-date, with a pretty large extra amount to pay.
There were quite a few stories about this in the press at various times [0], and I know quite a few people from Klarna and would tease them about it - which they always strenuously denied - but then it happened to me.
In any case, finding out how this happened is going to be interesting.
[0] in Swedish: https://www.svd.se/mangder-av-klagomal-mot-klarnas-fakturor
DeepL translation: "Lots of complaints against Klarna invoices. Klarna, the high-profile IT company, is being criticised by a host of customers. Many say they receive invoices with reminder fees and collection demands directly, without having been reached by an original invoice. The Swedish Consumer Agency is critical of Klarna's invoicing methods for several reasons and is currently investigating whether the company is behaving legally."
Translated with www.DeepL.com/Translator
So what? It's 0% interest. It's incredibly helpful to have easy-access financing to split purchases across a few months.
>even simple things like buying a book through a web site requires declining several offers for paying with credit.
This sounds so specific it seems like you're taking a bad experience with one website and pretending all websites are like this. Most e-commerce sites I've used in the past year offer Klarna or some similar service and all of them have been implemented as just another option in a set of radio buttons.
Debt is slavery and so on. Let's not get too hung up on the fact that I dislike it.
> Most e-commerce sites I've used in the past year offer Klarna or some similar service and all of them have been implemented as just another option in a set of radio buttons.
Radio buttons is fine. It's the defaults and "are you sure you don't want to pay with credit?" questions I'm bugged out about. I don't have an issue with them offering it as an option. I've seen it with multiple websites using Klarna for payment handling.
No it's not, and statements like that trivializes the mistreatment that actual slaves went through.
I don't know, it seems like a failure at adulting to have to do that for small to medium sized purchases. If you need the feature, you probably should not have it available. Maybe this is my German attitude about money - basically, only take on debt for investments, a notable example being housing.
Unfortunately, this often isn't the case of people who are worse off, not good at managing their finances, and often overwhelmed by bureaucracy.
They fall behind on payments, and then get taken to the cleaners on fees, deferred interest etc., often paying several times the actual price of the product. I've seen this happen (with different but similar services).
Less savvy people being sold stuff they can't afford on credit has been such a problem that some countries have made it illegal to extend credit to someone who can't afford it, which is obviously extremely hard to enforce.
This is hard to grasp for many here, because HN readers tend to be well above average intelligence. Try to think in terms of "imagine how dumb the average person is, and now realize half the people are dumber than that". Now add mental or physical health issues into the game.
For me there are so many red flags with all these services, as they basically "steal" your credentials to log into your online banking. And while they claim that they only use the credentials to make transfers they could as well look at all my other account data. I really wonder how such a scheme can be legal and how banks can allow this, as they normally tell people to never give their credentials to anyone. The situation of course recently improved with the mandated 2FA for logins and transfers, but still there are so many attack vectors in this model that it boggles my mind how it can still exist.
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.
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.
The same NemID is also used to file your taxes, look at all your health info, get married, everything basically.
Credit card payments are much lower security level, and they're basically forcing sharing credentials amongst all the sites you pay on.
We didn't need to scam anyone though, just have them verify that they were a Swedish resident (had a valid Swedish SSN and we're the ones ordering) :D
And I believe you can also use sms + password for online transactions.
I don't think it's good that users are taught to accept their primary citizen 2FA on any random website and app where the URL doesn't even show.
As far as I know most, if not all, of these scams have been perpetrated against the elderly. All operations (authentication, signing) can be initiated remotely with just a personal ID number, so the typical scam meant calling up someone and claiming that "an authentication must be performed", and simultanously initiating a bank login session. If you can keep the victim on the phone and using the BankID app when you tell them, you could basically login and empty their bank accounts. This has been largely fixed using QR codes to initiate login requests for major internet banks (which means you have to be in front of the same screen now) and other clever workarounds. But it has also always been a fact that there will be a description saying what you are signing, in the app, so being careful you could easily avoid being scammed.
I think its largely a great asset (BankID) but its never gonna be 100% tamper-proof without being seriously neutered.
Then again, PSD2 API roll-out has been very ???
They signed into users bank accounts, in other banks, to set up transfers (which also gives you all account statements).
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.
It's extremely useful for any ID verification, but Klarna asks you to verify your identity towards them but when you open the app they have instead sent a request to identify with your bank, using your credentials.
They provide "pay by bank account" (which involves the mentioned MITMing of users' online banking accounts, unless Klarna is integrated with your bank via OAuth/PSD2, which is still not ubiquitous), but also installment payments/factoring and others.
[1] https://docs.tink.com/market-capabilities/aggregation
In OAuth2 David only ends up with some token showing Alice authorised David to use this service on her behalf. Bob can tell David and Alice apart, and choose to restrict what David can do appropriately.
If Bob is particularly tired of this nonsense, and his customers like Alice keep giving David their credentials and then are surprised that doing so means Bob can't tell Alice and David apart, WebAuthn reifies it so that most users in Alice's position can now see where the problem is. When David tells Alice he needs her Yubikey to access Bob's service, it should occur to Alice that giving the Yubikey to David isn't a good idea because then she won't have it any more. Good.
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.
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.
[0] https://knowledge.fintecsystems.com/en/blog/the-history-of-o... , under "Legal Action by Giropay"
> how banks can allow this
A court decided that blocking this "business model" would be anticompetitive.
Edit: Found an article in German - https://www.sueddeutsche.de/geld/zahlung-per-sofortueberweis...
They claim they need to do this to make sure there is sufficient money in the account, even with transactions that might not be reflected in the balance, and they also check for other "Sofortüberweisungen" to detect fraud. Makes sense in a way but still quite shady. If there wasn't enough money in my account, or other transfers pending would my bank even allow their transfer?
But doing so has always been more confusing for me compared to “regular” payments with a credit card anywhere else, and has on overall been a negative experience for me.
I really don’t understand why anyone would prefer to use them at all.
What am I missing? Can anyone help me understand?
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.
https://en.wikipedia.org/wiki/Short_Payment_Descriptor
I don't see how credibility of website depends on what payment options they offer. That sounds like a separate issue.
The same can be applied to a credit card though so it's not a strong argument
Sellers get paid immediately and they take care of making sure the customer pays.
(Not claiming it's a killer feature, but it's a feature.)
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.
It may be different in different countries but the thing with the interest free credit is that once you don't pay on time it is converted into a revolving credit with high interest rate and something like a 60 months payment plan.
Klarna have also historically made up own names for fees to circumvent regulations for regulated fees. They were among the first to remove days of grace and among the first to use a fixed number of days from purchase to due date.
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)
https://www.theguardian.com/money/2018/nov/17/klarna-buy-now...
It's Payday Loans 2.0.
It's really disturbing to see Klarna as a payment option in many Dutch online shops. These always already have iDEAL (which the vast majority of customers use), a convenient way of doing an electronic bank transfer; and most shops support credit cards too.
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.
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.
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.
Is there more information on this? Are they doing the same thing Plaid does in the US? That is, literally asking for user credentials to internet banking instead of using the banks' proper APIs?
You can choose to pay at a later date
You can choose to split the payment into installments
It says a lot about the security of their api and development culture that they are even struggling with something like this. This should be caught in the first architecture review session.
Do you mean stuff like row-level security in the database tables?
I agree in general that you need to enforce things at the storage layer.
As a rule I don't cache personal information for this reason.
Out of curiosity do you have any knowledge on GDPR's stance on caching PI?
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.
0: https://github.blog/2021-03-18-how-we-found-and-fixed-a-rare...
If someone should be aware of thread-local storage and its implication it ought to be them.
We had built and authentication service that, among other things, was used by a SyncML service that was used back in the day of feature phones to syncs contacts etc. You can imagine that getting someone else's contacts on your phone isn't exactly ideal. This was how we came to know about the problem, from customers getting other customers data!
The error was caused by a CDN switch. Our instructions to the the CDN team responsible for the switch was "Make sure the CDN honors our cache headers, if our HTTP responses say something can be cached do so, if they say that the response should not be cached then don't". We were in at least three meetings where we repeated this mantra.
I believe that the CDN team thought that they had setup the CDN correctly but they had missed an edge case. The CDN was in fact setup to cache even uncacheable responses, and served those, _only_ when it could not reach our servers.
So if there was a traffic spike and the CDN determined that our authentication servers were unreachable it would fall back to serving data that should never have been cached in the first place! Happily returning tokens to random users that had authenticated just before the traffic spike...
I'm not sure what to think about this. My first thought is "Is this really legal?".
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.
Any request for data or information regarding their architecture is rejected on the grounds of 'trade secrets'.
I do know there are various legal requirements to retain certain data for some time (PSD2 for example must be stored for 13 months, I believe), but outside of that, it sounded to me like they tried very hard not to store anything for longer than necessary or without user consent.
I mean, doesn't mean its true, just the impression I got from the training.
If you have other information about other reasons they might have become a bank, I would be genuinely interested in hearing them.
Before pushing to production please finish this code and choose the id you want to use:
"select * from users where id = ?"
> user_id
> profile_id
> user_profile_id
> profile_user_id
> id
> rand()
I suppose that maybe comes down to your definition of what 'random' is.
Singletons are easy to understand, as long as they contain of one simple class. But after a few iterations of development, they tend to "capture" a lot of dependencies, which practically become singletons too. A lot of mistakes happen. And most of the time, there was no good reason to create a singleton in the first place.
see also those posts: https://stackoverflow.com/a/138012/4249619 https://stackoverflow.com/a/142450/4249619
1. They MUST NOT allow more than one instance. "I don't think anyone will ever need more than one" isn't enough. Just create only one instance then. Only enforce single instance if there is a requirement for it. For example, a logger is a bad singleton because you could conceivably want more than one instance. Something that requires exclusive access to some hardware may be a good candidate though.
2. The instance must be globally accessible. Many things don't need to be globally accessible though.
So unless you need a global enforced-single-instance of something, which in my ~20 years of programming is rarely needed, a singleton is a bad choice. In my experience, many times someone wanted only one instance, some time later it turns out that actually multiple instances would be useful after all (separate loggers for separate types of logs for example).
In most cases where singletons are used, a simple global would have sufficed. If you only want one instance, then create only one instance. If you need lifecycle management, then do something for that.
Those SO posts cover it nicely.
https://www.guidebooktolife.com/who-was-queen-scotia