Category: Technology

For those who don’t know, WordPress has a comments option.  In practice, reading article comments is generally of very limited value, but depending on the type of article and the people it attracts, the comments can at times still prove to be thought-provoking.  And what writer doesn’t appreciate the occasional thumbs up?  So I leave them enabled.  However, in order to ebb the potential abuse of said comments option, WordPress has various controls in place.  I keep the defaults enabled, which require the user to self-identify.  Obviously, there are problems with that policy.  But, the defaults also require the admin to personally approve each initial post from an individual.  Consequently, I’ve gotten some spam comments, but I haven’t approved them.  For amusement though, I will post them here, with all information which could prove beneficial to the spammer appropriately redacted.

The first comment I received was from a “Jean Miller” in response to S/MIME Email Encryption:

Emails stored on some third party servers can never be secure. [REDACTED COMPANY NAME] on the other hand bypasses cloud storage servers making it very safe to send secure email. See [REDACTED URL].

There’s a lot wrong with this.  First of all, unless you’re self-hosting email, all servers are 3rd party, or 2nd party if you’re considering the relationship between yourself and the email provider.  In any case, you can’t generally determine what security measures are in place beyond the company’s privacy policy, and even that isn’t a guarantee.  And any email you send is going to someone else’s email provider, which is beyond your control as well.  And the communication protocol behind email itself doesn’t enforce encryption–that’s the problem with email as a whole.  Also, “the cloud” is just internet servers, sooooo you can’t bypass cloud storage for email, unless you’re considering self-hosted to not be cloud per se.

The second comment I received was from a “Web Scripts” in response to Pumpkins!:

i love funny stuffs, but i specially like funny movies and funny videos on the internet**

I read once that spam intentionally utilizes bad grammar.  The concept is that an attentive reader will immediately identify the message as spam, and thus ignore it.  This is to mitigate wasting time of the spammer, for presumably the attentive spamee in this instance would more readily identify a scam, whilst the non-attentive reader might not.  It sounds like a good theory anyway.  And what’s with the double “**”?  Is there more to follow?  Are there specific conditions under which this spammer likes humor that I should be aware of?  If nothing else, they at least honestly self-identified as a bot.

Lastly, I received a comment just recently from a “private event security services” in response to “Mantis“:

My family members all the time say that I am killing my time here at net, however I know I am getting experience every day by
reading such pleasant posts.

It almost sounds like a believable comment, as the grammar could be attributed to the “.de” domain, except I’ve never heard someone mention that the Scandinavians have any trouble with the English language (also, there’s the name that was used).  I’d like to think that someone somewhere just wanted to compliment my writing.  Except, who has family that actively criticizes one’s internet usage, unless they’re an adolescent?  On a related topic, France and Denmark are the only two foreign countries that I whitelist (after receiving numerous attempts by Russian and Chinese IPs to brute-force my mail server) because I had family over there for a time.  Interesting that a bot there found this site.

So there we have it.  I’ve turned an irritation into entertainment.  Only humans and fully-autonomous AIs may leave comments.

–Simon

As both a customer and a bank employee, I see the frustrations on both ends of monetary transactions.  Since we don’t pay for anything with cash anymore, and with cybercrime and fraud keeping pace with the exponential growth of technology, studying ways to protect oneself quickly becomes a rabbit hole of madness and despair.  Well fear not (rather, keep a healthy level of fear)!  I will use my experience in the industry to try to simplify this nagging question: how do I pay for things?  I will do this by tackling two subjects: Liability and Security.

Liability

Liability is simply: who is immediately responsible for fraudulent transactions?  I say “immediately” because ultimately the bank still has to investigate, but depending on the type of transaction, someone’s money is tied up in the meantime.  Also, ultimately customer loss is covered under different legal protections by transaction type.  I will explain.

For Debit Cards, customer liability is based on when activity is reported.  If a lost card is reported and then the card is used, that’s the bank’s fault for not deactivating the card.  If the customer waits 2 days, there’s a $50 liability.  Beyond that, up to 60 days, there’s a $500 liability.  Beyond 60 days, and the customer is not protected from the loss.

A second point on Debit Cards–it’s the customer’s money that’s tied up during an investigation, depending on how nice the bank is.  So even if you immediately report a lost card, and someone uses it to drain your account, you’re up a creek with no personal funds while the investigation is underway.  That’s an extreme example, but something to consider.

For Credit Cards, customer liability is also based on when activity is reported, but it’s far less important.  Technically, the law was very similar to Debit Card liability until the CARD Act.  Now, the 60-day rule no longer applies, so customer liability caps out at $50.  Even so, most credit card companies simply waive that paltry (to them) $50 liability for marketing purposes (pay attention to the next solicitation you get in the mail).

And, referencing the earlier point, a credit card is not the customer’s money.  While an investigation is pending, it is not the customer’s finances that are being held.  A stolen credit card is an inconvenience, yes, but a relatively minor one.

Security

Now that we’ve covered who’s responsible for what, we can address what is the safest method of payment.  Security is defined by 3 methods: something you have (a physical card), something you know (a PIN), and something you are (biometrics).  Security is enhanced as these methods are compounded.  To explain: a magnetic strip credit card only leverages a single method: possession of the card itself.  A physical swipe is all that’s needed for authorization.  This method fails when that account information can be flashed to blank cards, creating facsimiles (counterfeit fraud, in the industry).  Account information is stolen both on an individual basis by reading the unencrypted account number off the mag strip by a harvester (by anyone nefarious who has temporary access to your card), and from merchant databases (since merchants store your full account number for transactional history).

To address these problems, the EMV chip was introduced.  The idea is that a card would leverage a second factor of authorization: something you know.  In this case, a PIN would be coded into the chip with the account number and encrypted, thus preventing card duplication and rendering a card useless if stolen.  It also makes storing and stealing information less useful because transactions are assigned a session token, determined by an algorithm on the chip and applied to transaction-specific data and a terminal nonce; only valid for that transaction; which the bank takes as verification that it was your card being used.  This became known as the Chip and PIN method.

But, this method was neither standardized nor enforced.  EMV whitepapers include a number of possible applications, which translates to varying degrees of security of which the customer can’t readily determine.  And so, we also ended up with the Chip and Signature method.  This undermines part of the point by not requiring a second factor of authentication (i.e. the PIN).  The Chip and Signature method encrypts the account information and generates tokens in the chip, same as Chip and PIN, hopefully preventing harvesting the information and mitigating counterfeit fraud, but it doesn’t require a PIN.  You see the difference–a stolen card can still be used.

Also, until chipped cards are mandatory, many are still printed with a magnetic strip, defeating all the benefits of the chip.  The law shifted so that the bank can now force all liability on the merchant for not supporting chip technology, but nothing is legally required, so in the meantime we still have cards with insecure magnetic strips.

Now back to debit cards.  The original debit card was only a debit card.  It had an insecure account number in a magnetic strip, yes, but it required a PIN to authorize–so two factor.  A stolen card, therefore, was theoretically useless as the thief wouldn’t have the PIN.  But, then banks started leveraging the credit card networks to offset transaction costs, which is why you can run your debit card as a credit.  Running it this way doesn’t require a PIN, thus destroying the purpose of the PIN itself, and the money still comes out of your bank account.

So to date, we had a single-factor authentication card, came up with a couple two-factor methods, undermined one, haven’t standardized the other, and came up with a way to mitigate duplicating a card but haven’t standardized or enforced it.

The most recent enhancement has been mobile pay–specifically for this article: Apple Pay.  In this method, a secondary account number, derived from nonce i.e. the token, is generated and stored on a mobile device.  As in the way time-based authenticators are used, a cryptogram is generated at the time of sale from an algorithm, the variables of which are unique to the device itself and cannot be determined mathematically from the cryptogram or the token, both of which are submitted to the merchant for authorization.  A third element, a dynamic CVV, is submitted as well, another algorithmic derivative of the token and cryptogram.  The security lies in that that the token, cryptogram, and CVV output  are all required for a transaction, yet two of them are dynamic, and the cryptogram which ties together the mathematical relationship relies upon device-specific identifiers that are encrypted on the device and never divulged–only verified through the process–likely a hash (this is an overview, as the specific details are not published).  The point is that any information harvested in the transaction or stored cannot be used to determine the account number, nor re-used, nor applied to determine the cryptogram’s elements that generate the cryptogram/CVV.

Furthermore, the mobile pay method leverages the security of the customer’s mobile device, therefore enforcing two factor authentication (the phone’s password/owner’s fingerprint).  And, since all data is encrypted by default on an iPhone, stealing the phone won’t allow its use for payment.

Conclusion

For maximum security and minimal liability, use a mobile pay method of a credit card.  After this, I rank other methods in decreasing order of ideal security/liability combination: mobilepay/debit card; Chip and PIN credit card*, Chip and PIN debit card*; Chip and Signature credit card*; magnetic strip credit card, Chip and Signature debit card, magnetic strip debit card.

*Only if card does not also have a magnetic strip.

NOTE: I have yet to be issued a chip-only card.  So far, they have all been dual chip/magnetic strip cards.  Dual cards ultimately offer little benefits over magnetic strip only cards if the card is stolen, but do use the chip over the strip whenever possible as this still limits the use of stored credit card data.

Bottom line: use mobile pay if possible, and always use a credit card over a debit card.

Also, you might be wondering how a phone or internet transaction occurs, to which I say: good question.  If no one’s scanning the card/device, obviously the card’s security is moot.  Although, Apple Pay does integrate with iOS applications, so you can pay through the same device’s merchant application as Apple Pay.  And for EVVs, there is information regarding an out of band dynamic CVV generation….

Obviously we’re still working on the problem as a society.  I dunno, maybe pay with cash after all.

–Simon