Horrible customer experiences in Germany: Postbank

Over the years, I have encountered a disturbing number of truly depressing behaviors from various German companies, both privately and in my professional and business life, be it stemming from incompetence, from blatant disregard for the customer’s rights, or from an inability to understand that both parties have to keep up their end of the bargain. I intend to discuss some of them over time, starting with the events around the business account I until very recently held with the Postbank (a banking subsidiary of Deutsche Post, the German “Post Office”). I recommend all readers to without exception have no dealings whatsoever with this grossly incompetent and customer hostile institution.

In an incomplete account:

1. The account was supposed to come with a credit card, barring a vague disclaimer about credit worthiness. This disclaimer is fairly standard in Germany and something someone in good standing should be able to ignore—and I* earned well, had a bit of money put aside, and had never failed to pay a correct and undisputed bill. Still, I was refused a credit card, with the claim that these were not available to businesses* younger than, in my recollection, two years—something not mentioned with one word in advance.

   *Note that I work in a legal form that does not require the explicit founding of a company, implying that my credit worthiness as a business entity is (or at least should be) the same as my credit worthiness as a private person. This also makes the time limit applied harder to defend.

   No alternatives were presented (e.g. a debit or pre-paid card or a deposit).

   My request, about a year later, to look at the amount* of money in the account instead of the age of my business went without a reaction.

   *I will not discuss details of that kind here, for reasons of privacy. However, it was considerably more than I could realistically spend with the types of limits that apply to most German credit cards—and it had a history of rapid growth over the year that had passed.

   As a result, I was forced to use my private* credit card for e.g. booking and paying hotels, resulting in an unfortunate mixing of private and business funds/transactions, probably formally violating the terms of use for my private account, and removing many of the benefits with having a business account. Certainly, had I been told in advance about the business-age limit, I would absolutely not have opened my business account with the Postbank.

   *This credit card, as well as my private bank account, are with another bank.

2. The account was supposed to come with a fully functioning Internet banking (and is anything else even conceivable in the years 2015 and 2016?!?). This did not turn out to be the case: In order to take actions within the online banking, including executing money transfers, I needed mTans*. In a first step, this required entry of a cell-phone number, to which a text message would be sent as verification, after which everything would work. However, despite several attempts on several days and despite a fully functioning cell phone**, I never received this text message.

   *I.e. Tans sent to a mobile phone. Frankly, the technical problems aside, it is very weak of a bank to force some specific technology on the users in that manner. What if someone does not have a cell phone?

   **Including the ability to receive text messages, something I verified carefully through copy-and-pasting the phone number from the online-banking page to an SMS-sending tool.

   My requests that the Postbank fix the problem went unheeded. Alternative means to activate mTans or do online banking were not provided.

   With this, the remaining benefits of a business account were gone and, again, I would certainly never have opened the account, had I expected such problems.

3. As time went by, money accumulated on my business account from bills paid by my customers while my private account grew thinner and thinner, seeing that I had to pay all my costs, private and business, from my private account.

   I now wanted to transfer money to my private account and used one of the provided (paper) forms for an inconvenient and fee requiring* transfer. This transfer was never executed and I never received any notification as to the the “that” and “why”.

   *Whereas transfers through online banking, had they been possible, were free of charge.

4. A little later, I finally bought a suitable apartment (cf. earlier posts) and needed to pay the seller. This time I went directly to the bank/post office, bringing a number of documents, including identification papers, with me, so that this could be done directly in the office, with no possibility of a hick-up. At the same time I wanted to transfer the lion’s part of the remainder to my private account.

   What happens? The clerk hands me several forms and asks me to complete them—apparently unable to do anything of what I had expected. Well, if filling in forms was the only thing available, I could have saved myself the walk and the almost half-hour (!) long wait in the queue, and just done this at home with the forms I already had.

   I filled in the forms, double-checked them, had the clerk double-check them (comparing against the known amounts and papers with printed versions of the relevant account numbers). This while explicitly mentioning the earlier unexecuted transfer and having emphasized how important it was that nothing went wrong. The clerk had no objections whatsoever to the form contents and claimed that the money would be transferred in no more than three* days.

   *Considerably slower than with online banking. (But in all fairness, I likely would not have been able to transfer so large a sum in one sitting per online banking anyway. The transfers to my private account are different, because I could easily just have made a monthly transfer for a smaller amount.)

   I waited four (!) days and still found no trace of a transfer.

5. Come the next banking day, I went to another office, further away from my living quarters, where I expected a more bank- and less post-centric support from the external presentation, in order to terminate my account, ensure that the apartment seller received his money, and that every last cent of the remainder were transferred to my private account.

   Despite the exterior giving a “banky” impression, including having signs advertising various bank services, this office turned out to know nothing about banking, being virtually dedicated to postal matters. Not only that, the clerk I talked to this time was extremely rude and aggressive, from the first word on, apparently considering me an idiot for coming to them for a bank matter—never mind their own signs… In the end I was sent to a central office several kilometers away, where I eventual managed to find someone who was a dedicated bank employee.

6. This visit took half-an eternity, with time spent waiting for service, with explanations, research of what had happened to the earlier transfers, the filling out and signing of form after form, …

   As it turns out, the first transfer had been rejected due to deviations in the signature. That might have been acceptable (I certainly do not want others transferring my money) had I been informed—but I was not. (As an aside, pen-and-paper signatures are an idiocy, being far to easy to forge, and suffering from considerable variations when written by the same person on different occasions. However, that is not a problem with the Postbank but with the overall system.)

   The other two had been filtered out because the scanner had been uncertain about the amounts. This sound more like an excuse than a reason, but is not entirely implausible, with standard German and Swedish digits being somewhat different. However, what followed later is under no circumstances acceptable: Firstly, such ambiguity should have been easily handled by a human reader (remember that the original clerk had verified the correctness and, by implication, readability)—and they had explicitly mentioned the amounts involved during the phone call, without prompting, which proves that they had no problems reading the numbers. Secondly, again they had failed to notify me.

   For the money transfer to the apartment seller, the situation was now urgent, and the clerk recommended an “express transfer”—for which I would have to pay another 15 Euro. This despite the only reason the express transfer was needed was the incompetence of the Postbank… Having no other choice, not wanting to risk the seller backing out, I consented, but clearly stated that I would demand these 15 Euros back. As promised, the money was transferred the same day.

   However, the money transfer for the remainder was not executed at all. This despite there being no room for error, the forms having been filled out by the clerk this time, and again without my receiving any type of notification as to the “that” and the “why”.

   Instead, the amount from the second of my earlier transfers to the private account suddenly turned up a few days after this visit. In combination, this is an obvious, obviously deliberate, and gross violation of my expressed will.

   To boot, despite my account being unambiguously terminated, with the additional unambiguous demand that any remainders of my money be transferred to my private account, this remainder has still not been transferred—almost two weeks after the visit. (And despite the clerk’s claim that money from an account termination should be available within roughly one week, even when not otherwise transferred.)

   As a result, the Postbank is currently sitting on a significant amount of money that they have no right whatsoever to sit on, while I find myself short the same amount of money.

   I have no idea whether they intend to return it, let alone when—but I do know that I will file criminal charges, contact the German Bank Inspection (Bafin) with a detailed complaint, and instruct a lawyer to take steps to retrieve my money against any and all further obstructions by the Postbank.

As an excursion, I originally picked the Postbank for my business account due to the, so it was presented, large net of bank offices, virtually every post office also being a bank office. In reality, as I have come to understand over the last few weeks, most of the post offices are useless when it comes to banking matters—even when their signs claim otherwise. In reality, the number of offices to take seriously is quite limited and the service network is far weaker, not stronger, than that of the main competitors (e.g. Commerzbank, Deutsche Bank, and, locally, various Sparkassen). Mostly, everything that can be done is to fill out a form that is then mailed to a more central office.

Advertisement

The declining security of Linux (and sudo considered harmful)

Naive approaches to computer security have long been a thorn in my side, starting with the long lasting Windows assumption of a single user and user account on a system. (Originally explicit in that no second user account or user control was available; in the last ten-or-so-years in the form that the standard case is one user and one user only—who if at all possible should only ever work with one account.)

Unfortunately, Linux has also taken a turn for the worse over the years, often taken extremely naive approaches, prioritizing the convenience of the inexperienced user over security*, and opening holes that even a highly proficient user is often unaware of—and with more and more holes as time goes by.

*With the dual effect that those who want security have to put in a load of work (and likely still fail) and that many users are not aware of how poor their security is. Notably, the naive users might be pleased about the convenience—but they too are victims of the poor security. I would even argue that because they are naive, there is a greater obligation to protect them through implementing strong default security.

A prime example is the default file permissions (umask), which on most modern systems are set so that anyone can read the files of everyone else… This is so obviously wrong and idiotic that whoever is responsible should be taken out and shot. The obvious correct default behavior, and what matches the reasonable intent on almost all systems, are permissions where either only the owner is allowed to read a file or only the owner and the members of the files “group”*. One of the first things I do with a new installation is to restrict the default file permissions to owner only—if something else is needed for a specific file, I override the default.

*The standard file permissions on Unix-like systems divide the world into the owner, the group, and everyone else. By assigning users to a group, they can be given different access to certain files than “everyone else”, without being the owner.

This misconfiguration is particularly dangerous because it is unexpected, it is often only discovered when it is (potentially) to late, and it requires an over-average amount of knowledge to correct*.

*It is not enough to simply change the default setting: Each and every file that has already been created with that setting must have its individual setting corrected.

Another particularly annoying and dangerous problem is demonstrated by utterly conceptually flawed tools like sudo, pkexec, and polkit: Much like the execution controls in Windows, they assume that a user has a varying amount of rights to do things depending on how he does them. (E.g. through calling a command with or without sudo, or through giving or not giving a password to polkit.) While these tools are intended to increase security, they instead open up ridiculous security holes, and increase the likelihood both of users being given rights that the admins never intended them to have and of hostiles being able to achieve “privilege escalation”*.

*Roughly, an attacker starting with a certain set of rights that do not pose a danger and tricking the system into giving him more rights until he does pose a danger. This is a central part of cracking a computer system.

Consider sudo: The intention of sudo is that when a user executes the command X as “sudo X” (instead of just “X”), it is as if root (the main admin user) executed the same command. Now, what commands are allowed to “sudo” for a certain user is configurable, but this configuration can be a bitch. Take something as harmless as an editor: If the user can “sudo” the editor, he can now change system files, manipulate the password storage, read documents that should be secret, … The system is effectively an open book that a skilled cracker can exploit and infiltrate as he sees fit. OK, so we do not allow editors (and a number of more obvious things like command shells, commands to delete files, and the like). Now what about all the other applications that are not editors but still have the ability to execute editors or have the ability to even just save a file? What about those that can execute commands (e.g. through a “shell escape”—a very common mechanism on Unix-like systems)? They too must be ruled out. Etc. But here is the real devilry: How do we find out what commands have what abilities? This is a virtually impossible task, with many nasty surprises—e.g. that the standard pager (“less”; seemingly only intended to view files) has the ability to launch an editor… The only chance is to reduce the “sudoable” commands to an absolute minimum, carefully verify that minimum, and (more likely than not) conclude that the users now do not receive the convenience that sudo was intended to give them.

The task of configuring sudo is made the harder because most Linux distributions appear to work on the assumption that any system is a single user system (as with Windows above)—and cram down whatever gives the user convenience in the corresponding configuration. Looking at the configuration file /etc/sudoers on my current system*, I find e.g.

*No worries: While the configuration file is still there, the actual sudo program has been removed.

# Allow members of group sudo to execute any command

%sudo ALL=(ALL:ALL) ALL

The comment line says it all.

Now, a good admin would not assigns the group “sudo” to just anyone and would use far more granular settings to give individual users what they need. However, not all admins* are good and this approach practically invites the admin to be lazy and assign rights carelessly. To boot, this makes it ease for the Linux distribution to screw up, because the consequences of a change become hard to predict, e.g. when default group assignments or default configuration entries are altered. In one horrendous case I heard of some months ago, the default configuration actually gave everyone, irrespective of group, the right to “sudo” anything, resulting in a system with no actual security anymore…

*Note that the admin is often quite, quite poor as an admin: Admins are not just found in big enterprises—the family member who takes care of the family’s computers is also an admin.

Others do truly stupid things, like https://help.ubuntu.com/community/Sudoers which gives an example of how to add an editor (!) to the configuration—and this in a section titled “Common Tasks”…

myuser ALL = (root) NOPASSWD:NOEXEC: /usr/bin/vim

This example lets the user “myuser” run as root the “vim” binary without a password, and without letting vim shell out (the :shell command).

Well, preventing “shell out” (more properly “shell escape”, one of the issues I mention above) is good, but obviously the idiot who wrote this has failed to understand that an editor is lethally dangerous too (cf. above). For instance, “sudo vim /etc/shadow” gives a malicious user the possibility to change the root password, after which he can trivially gain a root shell—without needing a “shell out”.

In contrast, the earlier approach was very sound: Either a user account had the right to do something or it did not—end of story. Usually, “did not” applied, when not dealing with the users own files. When more rights were needed to do a task the physical user had to log in with a new user account with more rights in the relevant area (and typically less in other areas!)—if he was trusted with such an account*. Yes, sudo can be more convenient, but that convenience is bought with a horrendous drop in security.

*If he was not trusted, then he correctly had no opportunity to do whatever he wanted to do.

The one saving grace of sudo is that it makes live a little safer for those who would otherwise take even greater risks in the name of convenience, through giving themselves dangerous rights all the time. This, however, is not a valid reason to make life that much less secure for the users who actually try to be secure and know how to handle themselves. This is like noting that condoms reduce pleasure and replacing condoms with some other mechanism which gives more pleasure—but does so at the price of not actually preventing pregnancy and disease transmission…

As a rule of thumb: If someone recommends that you use sudo, discount anything he says on security issues. This tool is simply one of the worst security ideas in the history of Linux.

I have seen some truly absurd cases, e.g. one nitwit who adamantly insisted that logging in as root on a terminal was very dangerous, but still threw sudos around willy-nilly. (While logging in as root is never entirely without danger, a terminal is the least dangerous place to do so, seeing that this reduces the risk of a snooper catching the password, removes the temptation of starting various GUI programs, and drastically reduces the risk of forgetting that one is using the root account and mistakenly doing something stupid.)

Excursion for the pros:

Those who know a little more about Unix security might see a major advantage of sudo in the reduced need for suid-ing programs. This might or might not have been an advantage at some point of time, but I have worked for years without using sudo and I have never needed to change anything in this regard. I conclude that what should work works, be it through appropriate group settings, daemons, or suid programs that are there irrespective of the presence of sudo. In addition, I am not convinced that suid programs, the potential dangers notwithstanding, are a greater evil than sudo, at least not after considering the relative likelihood of an admin doing some stupid—it is not just a question of what approach is the safer technically, but also of what approach gives us the better protection from human errors.