Jason Pearce

If I didn’t know better, I would have thought that the Verified by Visa service offered by arcot.com was a man-in-the-middle attack that was poorly designed to look like a trusted service from Visa (my credit card) and USAA (my bank).

Why your instinct should be to not trust arcot.com

Here’s a few reasons why my instinct was to distrust both Verified by Visa and arcot.com:

• https://secure2.arcot.com/ was not united.com, where I began my purchase
• https://secure2.arcot.com/ was not visa.com, my credit card
• https://secure2.arcot.com/ was not usaa.com, my bank
• https://secure2.arcot.com/ was asking for personal information (name, credit card secuirty code, expiration date, and birth date) that I had already provided united.com
• https://secure2.arcot.com/ has an unprofessional text-only website that reads “This is Secure2.arcot.com. This is the Arcot OBO verified by visa service. Please visit visa website for more details.” Notice it has no outgoing links, so no referrals traffic would be noticed by visa.com
• https://www.arcot.com/ doesn’t exist and displays an SSL Connection Error (error 107)
• http://www.arcot.com/ automatically redirects you to http://www.ca.com/us/multifactor-authentication.aspx, which is yet another party
• USAA’s website has no mention of arcot.com
• Visa’s website has a few mentions of arcot.com buried in PDF documents
• United’s website has no mention of arcot.com

Why Verifed by Visa and arcot.com looked like a man-in-the-middle attack

A MITM attack requires that the attacker place himself between two parties that are trying to communicate (me and united.com) and impersonate at least one of the parties (look like Visa or USAA). The arcot.com site required me to enter my name, the three-digit security code on the back of my Visa, the expiration date of my card, and my birth date — all of which was information that I already provided to united.com.

arcot.com has a very weak password policy

I knew arcot.com was legit even though it’s behavior is quite suspect. I believe a newegg.com purchase first exposed me to this process. But this time, arcot.com required me to create a password for their service.

Their password requirement reads: “To create your password enter 6 to 10 characters, without spaces.” But each time I entered a password, it would get rejected by this message: “Your password does not conform to the Password Policy. Please try again.” The is no link to a Password Policy and the link to Help does not contain information about their password policy.

Here are the five passwords I attempted:

• hup52!eChu
• XeW=A#rA5&
• #re_aqeS7s
• 4racrE$rec
• beNu&Em9fu

Each of which is between 6 to 10 characters and would take a desktop PC about 58 years to crack). What ended up working was a much weaker alpha-numeric 10-character password that would take a desktop PC about 6 years to crack. That was the best level of security Verified for Visa and arcot.com afforded me.

Password limits imply poor security

Restricting users to a small selection of characters and a length of 6 to 10 characters gives the impression that arcot.com is storing user-entered passwords in an insecure form (like plain text).

The best practice for collecting and storing user submitted passwords is to:

• Permit any character (entropy)
• Permit an unlimited number of characters (length)
• Add salt (unique random data added to each user’s password)
• Hash the user password with appended salt (algorithm to change variable length data to a fixed length)
• Re-hash several times (fixed is fine, but random per user would be better)
• Store the final hash in an encrypted database, the unique-per-user salt in a separate encrypted database, and the random-number-of-hashes-per-user in a third encrypted database — each database on separate systems with separate credentials

Because arcot.com limits me to 10 alpha-numeric characters, I’m given the uneasy impression that they do not hash my password. If they did hash my password they would not care if I put in 20 characters or 2,000 characters, the hash would produce the same 256-character result (regarding length).

Shame on United, Visa, and USAA

Shame on the three of you for working with a third-party service that looks like a man-in-the-middle attack. I applaud you for wanting to improve your security and reduce online fraud, but this implementation is terrible and leads me to question your priority for security.

If you want to increase a security layer, do so from your own sites (which we trust) and not from a website we’ve never heard of. Use of subdomains would be fine. Additionally, permit users to enter very long and very complex passwords. Tools like LastPass automate this process.

Visa and banks in particular need to be vigilant in teaching their customers how to be secure and then practice what they preach. USAA has published several articles about online security and should be ashamed for having any connection to arcot.com’s Verified By Visa implementation.

Last week I performed an in-place upgrade from VMware View 4.6 to VMware Horizon View 5.2. Things mostly went well, though I have a few remaining issues waiting to be resolved.

SSL Certificates

View 5.2 has more SSL requirements than 4.6. Out with the self-signed certs and in with certificate authority certs.

When it came to SSL documentation, nothing beats Derek Seaman’s blog. Here are the most helpful resources:

• Create Windows CA VMware Certificate Template
• vCenter 5.1 U1 Install: Part 2 (Create vCenter SSL Certificates)
• VMware View 5.1 Installation Part 1 – View Connection Server

Thank’s Derek for the great documentation.

VMware documentation

In general, VMware’s documentation is quite good. I greatly appreciate that they publish their documentation in HTML, PDF, epub and mobi formats. Thanks so much for the mobile versions.

I did find two errors in their documentation that I’d like to point out and correct. I have provided VMware both corrections and they have acknowledged receipt.

Firewall Rules for DMZ-Based Security Servers

Incorrect: Security server > TCP Any > MMR > View desktop > TCP 4927

Correct: Security server > TCP Any > MMR > View desktop > TCP 9427

Upgrade View Security Server

Incorrect: Prerequisites > Verify that you have a domain user account with administrative privileges on the hosts that you will use to run the installer and perform the upgrade

Correct: This prerequisite should be omitted. VMware View Security Servers should not be on the domain and do not require a domain user account to perform an installation or upgrade.

Firewall Diagram

Thank you to Ivo Beerens for posting a nice diagram of the firewall requirements for View 5.2 in your “Tips for implementing a VMware Horizon View Security Server” post. My network engineer and I greatly appreciated it.

External View 5.2 Problem

My remaining problem resides with the View 5.2 Agent and external access. If I publish a desktop pool using a VMware View Agent version 4.6.0 to 5.1.3, external PCoIP works well. If I upgrade the desktop pool to use the VMware View Agent version 5.2.0, I am unable to establish a PCoIP connection (RDP works). Internally, PCoIP with the 5.2 Agent works fine.

I have an open ticket with VMware and hope to have this resolved so that I can complete my View 5.2 upgrade and begin working on my VMware vCenter upgrade.

Less than two years ago, my mom and I began a sheet music website called ScoreVivo.com. Today, we published our 100th sheet music arrangement or original composition.

It all began when one of my mom’s traditional publishers was going out of business. When I learned that she could not simply choose another publisher (because she no longer owned the copyright of the work she created), I suggested we go out on our own. My knowledge of web development and her network of musicians might have a chance.

We launched the site with 10 of her arrangements. Today, we have 13 talented artists selling a total of 100 arrangements and compositions. While most of our sheet music is for flute ensembles, we have several that are for string, clarinet, and hand bell.

What I like most about this endeavor is how we are not a traditional publisher. ScoreVivo does not own a single copyright for the music it publishes. By requiring our artist to retain copyright ownership of their work there is nothing preventing them from leaving at any time to sell their music elsewhere at any time, yet no one has.

And if retaining copyright ownership of their own work wasn’t enough, we pay them greater royalties each quarter and we treat them more like partners than clients.

As for our customers, we remain amazed at just how many find our small site and how many return. We provide them DRM-free high-quality PDFs of their sheet music that they may immediately download and print. As our selection grows, more than half of our customers purchase two or more items at checkout.

Thank you to all who are a part of the ScoreVivo website. Here’s to another 100 more pieces to come.

My employer recently purchased a Pure Storage solid state SAN. I had a lot of influence on this project and lead the technical proof-of-concept testing.

The Pure Storage team was great to work with. And while we did experience some problems during testing, their customer support responded quickly, took ownership, and resolved the issues — restoring our confidence in both the product and company.

I’m pleased with the product and appreciate the opportunity to say so publicly via a press release and case study. Here’s an excerpt.

For the case study, you’ll have to provide Pure a little bit of info.

Addendum: 2013-Mar-15

TechTarget’s SearchSolidStateStorage article

A few days later, TechTarget interviewed me and published this “Hospital deploys Pure Storage all-flash storage for EHR, VDI” article.