Vanguard conditioning users for phone phishing atttempts

I am not a security expert, by any means, but my experience with Vanguard this morning left me with concerns about their security practices.

This Morning

My girlfriend received a call from someone claiming to be an employee of Vanguard. Without providing any verification, this person then proceeded to ask for the answer to one of her security questions.

If username and password are ever compromised, the security questions are the next (and possibly last?) line of defense against hacking an account.

My girlfriend immediately hung up and called Vanguard back to confirm their identity. Eventually, we were able to verify that they had, in fact, phoned.

Recipe for phishing?

Maybe I’m just being paranoid, but it seems to me that Vanguard is actively conditioning its customers to expose themselves to phishing attempts in the future. If Vanguard is willing to call and ask for this info, why not ask for more credentials down the road?

I called Vanguard back to discuss this phone protocol. Unfortunately, they do not publish a direct number to their security department. Even after speaking to several levels of management, I was never connected with a security expert.

Vanguard’s Response

At the top of the management chain with whom I did speak, I received two important pieces of information. First, this manager claimed that issues like these would become less meaningful in the future when they roll out voice recognition based security protocols. There was no timeline given for an official release (she did mention a Beta coming soon but wide adoption seems far out). Second, the manager acknowledged that this is probably a security hole but that it’s a tradeoff that they are willing to accept for smoother customer operations.

It seems, it would be too clunky for Vanguard to call a customer and ask that customer to call back on a secure, publicly verified phone line (or log in through the secure website).

I found all of this deeply troubling. Vanguard should have the highest possible standards for security. Am I off base here, or is this a really bad security practice?

About these ads

Beefing up the Python Shell to build apps faster and DRYer

One of the great mantras in Python is avoid repetition. And yet, when working on a Django app or with a new third party library, I often find myself stuck in the same pitiful cycle:

Start the Shell; encounter a bug or unexpected behavior; close the Shell; make some changes to my code; restart the Shell. And so on….

This sucks. Not only does it end up wasting 3-4 seconds for each Shell restart on my Macbook Air (those seconds really add up over time), it also inevitably leads to soul crushing frustration.

As an alternative to incessantly restarting the Shell, you could use the builtin Python reload() function, which reimports a given module within the program. Unfortunately, issues still crop up:

  1. reload() must be passed a module as an argument, meaning you have to import the entire module at some point in your program.
  2. Typing reload(module_name) still takes too much time if done ad naseum
  3. Django modules can’t be reloaded normally due to the AppCache singleton.
  4. People forget about the builtin in the heat of the moment, it just happens.

My solution (inspired by the builtin, multi-threaded Django server) was to add an auto-reloading thread to Shell_Plus.

Shell_Plus, an the extremely helpful script found in the Django Extensions library, is a Django Management Command which spins up an embedded Shell. Within the embedded Shell, the script sets a number of objects in the global scope on startup via (i.e. your Django models and settings variables).

The major change here is that, before entering the mainloop of the IPython Shell, a Watchdog observer thread (another great library) is kicked off, which listens for file system events. When a relevant event occurs, the thread automatically reloads the module into the global scope of the embedded Shell via a global dictionary. It’s fast and completely transparent to the Shell user.

This rather large gist (github) contains the code for the reloader thread, along with a heap of documentation.

At this point, I should mention that I decided to add some black magic to make the reloader as powerful as possible.

When a class definition is changed in a file and reloaded in the shell, all of the instances of the old version of that class inside the Shell’s global scope are dynamically assigned the reloaded class.

old_instance.__class__ = RefashionedKls

The implications of that last point are a little crazy. While inside a pdb debugger, you can add, delete, or modify class methods and immediately see the result inside the Shell session. I’ve used it to great effect while debugging and generally experimenting with code but the danger is obvious so beware. Again, check out the gist to see more details.

You can find my Django Extensions fork at github.

Even if you are not developing a Django app specifically, you can build off this concept of auto-reloading embedded Shells for any Python project.

Denial, anger, bargaining, depression, and acceptance: The A/B testing lifecycle

If you build it, will they come?

At Yipit, we are constantly looking to build cool new stuff without burning cycles on ideas destined for failure.

To stay on the right side of the ledger in this regard,  we’ve deeply tied our development process to analytics.  The company motto is “be a scientist”, which incidentally makes for great memes during our weekly company meetings.

Always be testing

To be considered during sprint planning, a feature normally must relate back to a testable hypothesis which attempts to predict its impact on key company metrics.  If the upside of a hypothesis is promising enough,we will move quickly to prototype the feature, utilizing a combination of internal and third party A/B testing tools.

As a developer at Yipit, I have become intimately familiar with the psychological ups and downs of experimentation.

Much like a someone suffering from grief, running serial A/B tests can drive you toward a path of extreme emotional states.  Here are a handful of the tell-tale steps that you may recognize in some of your A/B testing co-workers:


Wait, it’s down 10%?  That makes no sense.  Some javascript must be broken.  Is the HTML valid?  Did our acceptance testing miss something with IE(6|7|8)? Shit, what is the usability like on your iPhone?

Let me go ahead and bother my friends outside of my company and ask them to check out the app to confirm everything is in order.  They’ll gladly interrupt their lives to figure out whether the modal window is opening in 300ms or less.


Hmm, it’s all working?  Well, the new variation would be performing better if Google stopped sabotaging it.  Their stupid algorithm is heavily weighting views toward the control version. I understand that the variable group is underperforming by 20% and Google Content Experiments are set up to stop the bleeding, but just give it a fair shake for a little bit!

Maybe if I refresh the page enough times, things will change.  I just wish it were not 3AM in the morning…


Even if the variation is 3% worse than the control group, we can still justify the feature.  It may not be ideal in all respects but it fits into our overall strategy and it looks great aesthetically.  You could make the argument that it helps [insert some fringe metric] while hurting the goal we’ve defined here.  Maybe we should reassess our KPIs?

Worst case scenario, at least we’ve learned something here for future tests [no, you have not].  We are now one tweak away from cracking this wide open [no, you are not].


This is an abject failure, I realize that now.  The change would single handedly undo months worth of good work by other people at the company.

I guess that I can’t intuit everything about user experience on the internet. All of my days spent reading generalized ramblings on UI/UX were for naught.

I have no discernible skill in this dimension that is meaningfully different than any other intelligent person who cares to spend the time.  Who am I and what is my place in this online ecosystem?


Yes, the test has failed, time to move on to something else.  Speaking of which, the logged out homepage looks pretty suboptimal.  Wait, one second, how could I have been so blind?  It’s obvious, I just have to push these pixels down while jazzing up the copy [start the whole cycle again].

On a more serious note

The most important lesson that I have learned in my life has been that you should train yourself to avoid results oriented thinking at all costs.  If the process is good (and the A/B tests plentiful), it will all work out for you in the long run.

Speaking of which, I am running an A/B Test on this blog as we speak.  How do those 50% of you receiving free iPhone 5s feel right about now?

Enjoy this post? Follow me on Twitter