Related to Encryption

[mikho]

LMA0Sec


Liked the companyname.

 

[peterw]

What I want to know though is why anyone is storing reusable payment credentials (cc#'s etc) in whmcs anyway.  Usually you get an opaque token from the payment gateway and use that when you invoice.  If the token gets stolen the attacker can't use it to send money to himself or to access customer cc#'s.  He can only issue invoices through the payment provider, which doesn't help him and which have a hold period.

I only work with tokens on my projects. I do not need any customer or creditcard data to start payments.

All big payment processes do support this through webservices.

 

[perennate]

Hi I'm texteditor I'm also a security researcher and a grown-up (not a kid!), my fave security to research is Hackforums and l33t script kiddie fights wats ur fave security topics?

James Z.

CEO & Lead Security Researchist @ LMA0Sec

Hi, are you looking for more staff? I can send you resume... and screenshot of my ID. I need job please hire.

 

[tchen]

@KuJoe I think that he was referring to pass the key using GET, bookmarking the url should automate. 


I dont like it... I mean the thing is  to NOT store the key. Inputting the key for each new session should not be too much work. Usually you login and work at the current session for hours if not days.

Passing the secret key on the querystring is forbidden. It's cached in so many places along the way it's not even funny. In any case, best practice for the key vault was suppose to be on a system that was different than the encrypted datastore, and with far less network access. Whmcs just barely allows you to meet the self audited PCI compliance, but any higher level security audit would tell you not to put either the database nor encryption keys in the DMZ.

 

[Hxxx]

Passing the secret key on the querystring is forbidden. It's cached in so many places along the way it's not even funny. In any case, best practice for the key vault was suppose to be on a system that was different than the encrypted datastore, and with far less network access. Whmcs just barely allows you to meet the self audited PCI compliance, but any higher level security audit would tell you not to put either the database nor encryption keys in the DMZ.

Again, you could just input the key one time in a session and passing it through post ( with SSL )to a session variable. The purpose of this post is to discuss best ways, some people has more experience than other, probably there are many other ways better than the one I just said. The thing is not to store the key anywhere, nor online or offline.

 

[KuJoe]

Again, you could just input the key one time in a session and passing it through post ( with SSL )to a session variable. The purpose of this post is to discuss best ways, some people has more experience than other, probably there are many other ways better than the one I just said. The thing is not to store the key anywhere, nor online or offline.

I guess if it's not for a billing system then that is the best way to do it, but for a billing system that would basically cause the system to be useless for any normal size company.

 

[tchen]

Again, you could just input the key one time in a session and passing it through post ( with SSL )to a session variable. The purpose of this post is to discuss best ways, some people has more experience than other, probably there are many other ways better than the one I just said. The thing is not to store the key anywhere, nor online or offline.

Nothing personal, but your workstation is not a valid place to store the key. The best practice to limit scope is to use a tokenization service, either as a PaaS like Stripe or internally. With it, you have ACL level control so you can provide access to say multiple people in accounting without passing around the keys. Throttling and monitoring on the service api calls contains any authentication breaches.

 

[Hxxx]

Nothing personal, but your workstation is not a valid place to store the key. The best practice to limit scope is to use a tokenization service, either as a PaaS like Stripe or internally. With it, you have ACL level control so you can provide access to say multiple people in accounting without passing around the keys. Throttling and monitoring on the service api calls contains any authentication breaches.

Can you point where at any point in the discussion  I've suggested to store the key in a workstation? This reminds me of the first line of support in ASO. They just don't read.

 

[joepie91]

What I want to know though is why anyone is storing reusable payment credentials (cc#'s etc) in whmcs anyway.  Usually you get an opaque token from the payment gateway and use that when you invoice.  If the token gets stolen the attacker can't use it to send money to himself or to access customer cc#'s.  He can only issue invoices through the payment provider, which doesn't help him and which have a hold period.

What I want to know, is why an archaic banking system with a low-entropy shared key mechanism is still in wide use.

 

[tchen]

Can you point where at any point in the discussion  I've suggested to store the key in a workstation? This reminds me of the first line of support in ASO. They just don't read.

Okay...


1. Again, you could just input the key one time in a session and passing it through post ( with SSL )to a session variable.


Which implies that somewhere, that secret key is near your workstation. Either on disk, USB, on a piece of paper or in your head,


2. The thing is not to store the key anywhere, nor online or offline.


You say 'not offline' very matter of factly as if it's easy. But taking the quip strictly means it reduces to a pass phrase in the head encryption which is historically very weak given that most people can't memorize a sufficiently long high entropy string. A compromise of your 'encrypted' store will be decrypted quickly via brute force. I gave you the benefit of doubt in that you didn't strictly mean it given the consequences of such a scheme.


Instead, I figured you meant the very slightly better standard practice of having a pass phrase protected private key that's unlocked like ssh passwordless auth. But I apologize for jumping the gun there.


P.S. There's no need to be a dick.

 

[tchen]

What I want to know, is why an archaic banking system with a low-entropy shared key mechanism is still in wide use.

I looked up why they haven't adopted 2fa giving how much they're pushing clients to be online only to save costs, and it turns out it's primarily convenience factor. Given that their liability is already reduced because you're responsible for keeping your 's3cr3t' secure, they feel no need to push better security onto their clients. It's only going to be when more people ask for it or their support costs rise that they'll budge.