Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

What is the actual security concern here? Do you think they are storing passwords in cleartext? It's not clear that is the case because they generated the password. Suppose they chose a password for you and stored a secure salted hash in the their database, they would still be able to tell you what the password is because they generated it.

Are you concerned they sent you the password over e-mail? E-mail is insecure anyway and sending you a reset or create account link wouldn't be any better. If you're concerned about e-mail snoopers, what's is to stop the MITM from clicking on the link in your e-mail?

Are you concerned that they cc'd your contact person? If you don't trust your payment provider to not execute insider attacks, you shouldn't use them. Period.

The only advantage I can see to sending a password reset/create type of link is protection against shoulder surfing attacks. But if you have malicious insiders in your company trying to steal access to things they shouldn't have access to, you have way bigger problems than this.

ed: tbh, it's just as likely they fired you as a customer because they felt you aren't worth the trouble of dealing with.



If they send a https password reset/create link, then the password is never transmitted in the clear and nobody knows it. In the case of an email snooper getting access to the password-reset link and clicking it before me, I would immediately know that there's an attack because, well, the password was reset to something different from what I entered, and I'd receive a notification about that, too.

If they generate and send a plaintext password, then anyone who gets access to that email, even months in future, can silently access the account. So there is a difference.

Also, the whole concept of having a cleartext password sent unencrypted anywhere at all clearly violates PCI DSS requirements - and it is Ayden's duty to comply and be knowledgeable about that.

There's not a question of good/bad service quality, it raises a question if they're meeting the bare minimum criteria to be allowed in payment business at all.


If they generate and send a plaintext password, then anyone who gets access to that email, even months in future, can silently access the account. So there is a difference.

Not if you change the password immediately.


True. But in any case, the simple PCI rules state that passwords for any account accessing the payment systems can't be stored or sent unencrypted period, no matter what.

There are many things where what's completely okay for 99% companies is unacceptable (as in, a valid reason to break contracts and incur penalties of size that can bankrupt the company) for payment processing companies.

So what does it say about the company and how they treat security? What are they doing in the parts that are more tricky to get right and less visible to customers? Have all their systems, including that one, had a proper external audit recently - and if yes, why wasn't it noticed?

They don't know the security rules that are mandatory for them?

They intentionally break them for some reason?

They are simply sloppy with security and don't check if 100% of their systems are done properly?

That some systems that they give their customers for testing are low-security and don't matter, but "don't worry everything else is done with a completely different attitude" ?

They were going to fix it but didn't notice it before the feature was already live?

Can you give me one single sane reason that would excuse them?


Regarding "If you don't trust your payment provider to not execute insider attacks, you shouldn't use them" - the trust is partly supported by a long list of things that a payment provider must do to reduce insider attack risks. This includes an obvious requirement that their contact person can't access or know the user's passwords.

So yes, if they're demonstrating that they can't be trusted to do even the basic precautions for preventing insider attacks, you shouldn't use them. Period.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: