I spent some time today trying to replace pg but I ran into an issue. When using an rds proxy with iam authentication, it seems to repeatedly retry authentication and eventually my lambda functions time out. If I switch to using regular credentials it works fine. Using the exact same options with pg+iam authentication also works fine which leads me to believe it's an issue with this project.
It was indeed the RDS Proxy. It appers to be very strict about the client_encoding parameter. Postgres.js was sending 'utf-8' which PostreSQL will understand, but RDS Proxy would just hang until this was changed to UTF8 (uppercase with no dash).
I called my bank the other day and they asked over the phone for my password. This isn't a bank I often use, I only currently have a loan through them so I've never used the login on the website. I said I don't remember setting a password. They gave me a hint about the characters in the password and I was able to remember the password based on their hint. I verbally said the password character by character and they confirmed it. This is an example of how to not handle passwords in 2016.
Same thing happened to me, my local credit union emailed me my password. They ensured me that they use "bank-level encryption". Of course I didn't get into the difference between one- and two-way encryption with the teller, or that email isn't secure.
We live in an age where this should be unacceptable. Why aren't there financial security laws yet?
It's so infuriating because I've worked at companies doing digital commerce before, and PCI compliance and certification is quite onerous. But at the end of the day credit card numbers still aren't as sensitive as bank logins, yet there are no security standards on bank logins! It's crazy.
PCI compliance is pretty interesting. It's been many years since I worked in an e-commerce shop but I seem to remember that it even described physical security layers i.e., dictating the placement of door hinges to server rooms.
> I don't think banks actually care about individual user login security too much. Credit Cards reallllly suffer from security breaches though
But the only reason that banks care so much about credit-card security breaches is that the law forces them to do so. If the law didn't make credit card fraud the bank's responsibility, then they'd be just as lackluster about preventing it as they currently are about securing login credentials.
I don't know if that's true. Say we lived in a world where those regulations didn't exist and the fraud risk was on par with what it is today. If one bank introduced their own fraud protection program, wouldn't they basically capture 90% of the market overnight?
This is a good argument, but I'm not sure that I buy this. There are plenty of industries (I think of the cable and cell-phone industries, but I'm sure there are others) where it's just a given that the service will be crappy, even though one company that started to respect its customers could seemingly corner the market. (I'm not sure what are the results of T-Mobile's exercises in respecting its customers. Their unfortunate net-neutrality stance with Binge On means that it's not an unalloyed win to go with them.)
I get what you're saying, but credit cards are unique: the advantage credit card companies have over those other industries is that there is essentially no lock-in, and your old cards continue to work while you're in the process of switching eg your autopays over. It's a very switch-friendly industry.
Remember when you couldn't take your cell phone number with you and so pretty much nobody switched carriers? It was a massive pain. Now it's easier than ever to switch, except most people are locked into multi-year contracts. Switching friction = high, but not impossible. As you said, TMO is trying to compete here.
Cable has monopolies on towns, so there's 0 incentive. People couldn't switch even if they wanted to. I suppose there's satellite, but you'll still be paying the cable company for internet -- they get their pound of flesh no matter what. Switching friction = impossible.
What law are you talking about? PCI-DSS is required by the card companies and run an organization called the "Payment Card Industry Security Standards Council". It's self-governed essentially. It's not federal law
I hear credit unions are not regulated as well as banks, so even if there are laws for banks, the credit unions don't necessarily have to comply. Credit union security will probably always lag behind banks. :(
I once had to call my bank a few years ago to disable my debit card. The reason was that I inserted it in an ATM and the ATM had chosen that exact moment to malfunction and shut down!
The operator on the line asked me a ton of questions starting from my user-id (but not password), date of birth, full name, father's name, place of birth, type of account and many others that I don't remember now. Only after I correctly answered all these questions, did he start acting on my instructions.
My bank always asks me for: Birthday, Address and last time i got how much money. The first 2 details can be easy (in my country there is a website which shows this for most people who dont know how to stop them), the third one can be easy if you stalk me a day or two.
But if i tell them to not make it that easy, i cant manage my shit over the phone anymore :/
I also hate the stupid security questions used to identify you which they always claim "add security". In almost all cases they decrease security.
Where did you spend your honeymoon?
What was the name of your first pet?
What is the name of the street where you grew up?
For any given person, a LOT of people know the answer to these kind of questions.
Also, I hate it when people use date of birth to verify identity. Medical people love doing this. Um, just check the person's Facebook and see when everyone wishes them a happy birthday, then go access their medical records?
I loathe security questions too, but those aren't even that bad! My credit union's default security question is "What was your first musical instrument?" I wonder how many guesses you get?? I always answer these questions with a long string of random characters.
LOL, check their Facebook pictures and see if they are playing an instrument in any of them. Most people don't play more than 1 instrument, so it's probably their first.
How many common "first instruments" are there for kids? Maybe 5? There's a pretty good chance you'll get it right without doing any research whatsoever.
It's not quite as bad as asking "what species was your first pet?" but not much better.
This is the real problem with security questions; the answer space is often so very small, and can be narrowed down even further with a little research.
Questions like "what was the first name of (your maternal grandmother, your first best friend, etc.)" are very common -- well, there are stats on most popular first names of given generations in different places. If you know what country the person is in, you can make a good guess at these.
By allowing people to set their own questions and answers instead of a) using a pre-defined list of questions b) forming questions from information about the customer that friends/acquaintances usually know or information that can be found via a Google search.
This is also incidentally the basis for how I generate unique passwords for every service except banks, communication, and other sensitive things. I want a different password on every website and don't want to trust any password-remembering software I didn't write. The same function works fine for generating answers to secret questions.
Not really. I don't oppose using a master password, which I don't use anywhere directly or store on disk anywhere. I just don't want to trust closed-source code to manage passwords, and want to be able to generate the password to anything from anywhere without having to carry around an encrypted table of stored passwords. In this case, I implement it myself, with the help of some common open-source Python libraries.
Have a look at pass [1], it's a minimalist tool in bash that is so simple you can easily make adjustments to it yourself. The codebase is very small so it is easy to audit. The principle is that your password are encrypted with your public key. You can then use git to keep running copies of your encrypted passwords on many devices.
I don't think you should out them publicly. Are you interested in having them improve their security model [1] or do you want to have what they have they done out in the open so that others can try to social engineer them and their customers might suffer the consequences?
[1] If so, tell them about this in a way that will get their attention without causing their customers or them any harm.
Always have a reasonable response deadline. For a security issue, above 1 month is unreasonable for a small deployment, above 3 months in a huge deployment in my opinion.
Bear in mind that giving the password over the phone has a different threat model to sending the password over a TLS-secured connection from your browser to a bank-run web server. Specifically there is a human in the call centre who is transcribing what you say. Using a partial password (give me letters X, Y and Z) is a way of mitigating the risk of call centre staff being able to harvest meaningful amounts of security credentials. This does mean that you need to be able to check subsets of the characters in the password, which rules out hashing the whole password in this case.
> This does mean that you need to be able to check subsets of the characters in the password, which rules out hashing the whole password in this case.
As you implicitly point out, however, it doesn't require any portion of the password ever to be visible to the call-centre employee; one can just supplement an individual hash by a collection of hashes of appropriate character subsets, and then (say) randomly pick among the available subsets.
note though, that this means you have a collection of hashes for the password that are each 3 characters or whatever long, which can be brute forced in essentially no time at all. Crack em all, lay them out according to what letters the hash is for, put it all together and you are done. Even just having 1 subset reduces your passwords security by that many letters, if not more (you can filter out dictionary guesses that don't match those letters and such)
nope. Salt is good for eliminating rainbow tables and similar vectors. At this level, let's just say you go after uppercase, lowercase, digits and 20 different symbols, (a total of 82 letters) you'll wind up with 551,368 possible combinations. The only way to make it "safe" would be to get a hash method that would take multiple seconds to run on good hardware. (as a comparison, I crack raw NTLM at something on the order of billions of hashes per second)
Back from 2009-2010, I did work as a web developer on an ecommerce site. A month or so in, I discovered that they kept all of the user password unencrypted in a database.
I went to my boss and explained that we can't do that. It's inviting exploitation. He responded to me that we had to keep them in plain text, in the database so that we could send them to users who forgot. If they can't login, they won't order product.
I have heard similar stories from other IT professionals. It's amazing that these operations aren't getting pwn3d twice a week.
I experienced this too many times with UK/US providers (e.g. Hostgator and Fasthosts).
They often ask for server root password or email/password combo for the client portal, even after you verify account ownership.
Seems that they don't have any other way to grant the technicians access to the server/my account, which is absolutely ridiculous.
I'll open an issue on GitHub tomorrow.