MivaPay and Customer Password Settings

[Bruce - PhosphorMedia]

Just noticed this on a 'newish' clients site:

Customer Settings "Minimum Password Length" is set to one. I know its a VERY BAD idea since they are already storing CC numbers via Authnet CIM, but the real question is "can this work with Miva Pay". (Assuming that it might be checking for something reasonable).

[lesliekirk]

Just noticed this on a 'newish' clients site:

Customer Settings "Minimum Password Length" is set to one. I know its a VERY BAD idea since they are already storing CC numbers via Authnet CIM, but the real question is "can this work with Miva Pay". (Assuming that it might be checking for something reasonable).

Interesting add-on question - why is the admin even allowing for a "Minimum Password Length" of less than what should be met for PCI Compliance (to pass the item(s) in the PA-DSS Checklist)?

Password Minimum Length 7 Characters or Greater
Passwords Require at Least one Letter and one Number or Punctuation Character

Wouldn't it be a better practice to have these items "baked in"?

[ids]

I was going to suggest too that it's probably a PCI issue rather than a MivaPay issue. They may be mutually exclusive. MivaPay has its own credentials (wall) to be able to interact with the "vault." My thought is you simply integrate MivaPay. The process will (or should) inform you of requirements during the integration process. So, if you MivaPay requires PCI-level passwords, it will tell you or not work at all. FWIW, I don't recall exactly, but I think I have had clients with MivaPay installed and the passwords were not PCI-level. But, I am pretty sure though that they weren't single character passwords.

Slight tangent towards Leslie's comment. Maybe Miva Admin-level Users should have the PCI-level passwords "baked-in" at a minimum?

Scott

[Rick Wilson]

MivaPay solves for this problem, because even is someone has access to your admin (due to a horrible 1 character password) they can't get any card data from the Miva Admin or database. So this is way better than any alternative method for storing cards they might use.

In essence MivaPay's PCI Certification isn't dependent on the store being well configured. With that said, if the store got hacked and cards skimmed via a Magecart type JS attack(which would be the likely vector in the case being described here) then MivaPay's PCI Certification wouldn't actually protect the merchant from any liability.

As a separate topic though, I will discuss with Product if we want to at some future upgrade start mandating better behaviors.

[Bruce - PhosphorMedia]

Well, if an admin had a 1 character password...I'd fire them :).

My concern, even with MivaPay is, if someone hacks a customer's account, since they are going to use the 'store card' feature, the can order whatever they want.

Just looking for more ammunition for when I bring this up with the client.

[ILoveHostasaurus]

Merchant has been receiving updates related to this, and several coming, to reduce the risk to fraudulent orders on compromised shpoper accounts, which are typically the result of compromised passwords of shoppers who use the same credentials everywhere. The changes will be designed to prevent unauthorized adding of new shipping addresses, changing the email address, etc.

[Bruce - PhosphorMedia]

Merchant has been receiving updates related to this, and several coming, to reduce the risk to fraudulent orders on compromised shpoper accounts, which are typically the result of compromised passwords of shoppers who use the same credentials everywhere. The changes will be designed to prevent unauthorized adding of new shipping addresses, changing the email address, etc.

Yea, perhaps an option to require Email verification on a change in address would be pretty easy to add and a relatively low stress task for customers.