The Australian Taxation Office stores passwords in plain text

The ATO stores passwords in plain text. I know this because they emailed me my password after I forgot it. Storing passwords in plain text is straight up bad security, a threat to Australian residents who are required by law to interact with the ATO, and easily avoided. When I complained, they appeared ignorant of the problem; in fact, they gave a hilariously misinformed justification of why their process is acceptable, managing to miss the point entirely.

The details

The ATO Publications Ordering Service (POS) is the service you need to use to get paper copies of various tax forms. Many individuals won’t need to interact with it (you don’t need it for e-tax) but if you file a tax return for a company or trust, this is where you get the forms. You’re directed to the POS from the ATO’s website. For some reason it doesn’t have a domain, but it does bear our government’s name, coat of arms, and copyright assertion. It’s apparently run from “commercial web hosting facilities”.

The POS requires creation of an account before you can order documents, authenticated by an email address and a password. I forgot my password, entered my email address into the password recovery form, and was shocked to receive this email:

ATO POS password recovery email

The two blanked-out pieces of content are the email address I was using and my password.

In order to be able to send me this email, the POS must store my password in plain text, or at best with reversible encryption and associated keys.

Why storing plain-text passwords is bad?

Storing plain-text passwords is bad because storing a password makes it possible for someone to access it. Who? I certainly don’t know for sure, but  people who might have some opportunity to access these passwords include POS technical staff, the contractor/s who developed this POS, administrators of the system on which the POS runs, and administrators at the commercial hosting provider. And, of course, attackers who might attempt to gain unauthorised access to such a gold mine, perhaps through someone who already has access. And anyone who gains access to or intercepts a password recovery email, sent unencrypted over the public Internet to an unfortunate POS user.

Storing plain-text passwords is unnecessary. For decades now, the only acceptable means of storing a password has been to store a hash of the password, not the original password. A hash is the result of a simple mathematical operation over a string of characters. As an over-simplified example, for a password comprising only letters, you could map each letter of the alphabet to a number (A -> 1, B -> 2, etc), then add all the numbers up to a single total, which you store. When a user attempts to log in, you perform the same arithmetic on the password that they provide, and if the totals match, you let them log in. You don’t need to compare the password they provide with the original password, and if some malicious agent does gain access to the stored hashes, seeing that my password hash is, say, 193, doesn’t reveal the original password. (Note: modern hashing algorithms are much more sophisticated, and the chance of finding a  password that produces the same hash value as the original is near enough to zero).

Again, hashing has been the only acceptable means of password storage for decades. Hashing alone still has significant weaknesses and there are many techniques for making it harder to recover original passwords from stored hashes, should someone gain access to them. Storing passwords in plain text should be criminal negligence.

The ATO is clueless

So I complained (you can too). I explained the problem and gave references to hashing and related solutions. I received a call from a governance officer who, being non-technical, naturally didn’t quite grasp what I was complaining about, but offered to get a response from someone technical. I received that response a few days later.

Sending passwords in plain-text email is not one of the most commonly adopted methods of password recovery among services with any respect for their users’ security. This response (from the “technical area”, remember) also contains the stunningly false statement

if the password email is intercepted, still they don’t know the userid and the website address so they can’t figure out where the password is going to be used

Well. The “From:” address in the password recovery email is You can see it in my first screenshot. This pretty obviously names the service where the password should be used.

The “To:” address is the email address to use as a login name. I blanked it out above.

The password is obviously the password.

So the recovery email is a complete key of where and how to log in. That someone “technical” offered this in response to my complaint is really, really scary.

And also misses the point entirely. I’m not complaining about sending my password in email, I’m complaining about storing it in plain-text at all, ever! I think I confused them by pointing out that their recovery email is how I know they’re storing the password.

It’s a serious threat

OK, big deal, who cares about the security of a service for ordering free tax documents. It’s likely, though I’m not sure, that the POS is hosted separately to any other ATO services, does not share a database with them, and thus the passwords are only useful for ordering documents. Except… that’s not how people work.

Some 60% of consumers reportedly re-use passwords. Even the minority who try to reduce re-use still probably have a small number of “strong” passwords that they use with trustworthy entities like their banks. Or governments. Oops. And even someone who tries really hard and uses a unique password for each entity they interact with would still likely use the same password for the government-branded POS as they do for other ATO services, like their AusKey.

Storing someone’s password in plain text threatens their security with other services, not just your own. It could be the credential to any amount of private information. It could be the first link for an attacker to bootstrap up to a complete identity theft. It’s no good blaming the user for re-using their password; it’s well known that people do. There are easy and secure alternatives to storing plain-text passwords and no excuses for not using them. That my government is so reckless with its taxpayers’ security just leaves me speechless. I mean seriously, can they be trusted to accept tax returns over the Internet?

Please complain to the ATO. Please don’t re-use passwords, not even with your government. Especially not with your government.

Update: Thanks Daniel Black who commented below that with a reference to the Australian Government Security Manual, which states “Agencies must ensure usernames and passwords stored in databases are hashed with a strong hashing algorithm which is uniquely salted”. I don’t know if this applies to non-defence agencies, but it should!

Another update: Looks like this post will effect some change, at least to this service: SC Magazine.

Attracting engineers

A few weeks ago I wrote about the challenges non-technical entrepreneurs face finding good developers to build their idea. But even for a capable entrepreneur, finding talent and getting that first bit of interest isn’t the end of the challenge. I’ve seen more than a few smart, well-networked, -resourced and -researched entrepreneurs struggle to attract technical talent to a genuinely promising business because, well, us programmers are odd types and you need to understand what we want. Many aspiring entrepreneurs seem think that developers will be attracted to the same things that they are: an impossibly huge ambition, constant uncertainty and change, a statistically unlikely shot at millions of dollars, that kind of thing. For better or worse, that’s not generally true. Remember: great engineers have many attractive options. To attract them to your company you need to understand what they want, and make sure you can provide it (along with the entrepreneurial excitement).

Everyone’s different, but in my experience really good technically-minded people tend to value two things above all else: working with great people, and working on technically interesting problems. Working with great people–at least as good as oneself–amplifies the impact of your work. When you can trust that your peers are capable, motivated, intelligent problem-solvers it’s easier to see how your work will be valuable as part of a quality end product, as opposed to a jewel buried somewhere in a steaming pile of code. Talented peers will appreciate your talent and effort and be best able to arrange their own work to complement yours. Great people provide constant opportunities for learning: from how they work, from their existing expertise, and together as you explore new ground. And the best technical minds will attract even more great people to work with them, compounding all these benefits. Working with great people is the number one attraction for most good developers I’ve met.

Interesting problems are a close second. Solving problems is the essence of working with computers: problems of domain modelling, problems of complexity, problems of user interface, problems of scale, and so on. Sure, developers and engineers spend a lot of time writing code, expressing their solution formally, but the really interesting bit is solving the problem in the first place (often concurrently with writing the code). That’s also the most valuable part to your company in the long run. Solving problems presents constant challenges and opportunities for growth and learning. Solving hard problems, especially in collaboration with talented colleagues, is a realisation of one’s potential, the very top of Maslow’s hierarchy viewed through an engineer’s eyes. Without interesting problems, a developer is likely to get bored and realise their job could be done by someone with lesser talents. Now, you might not have technically interesting problems early on in your new company (the problems of making sure you’re building the right product are far more urgent), but you need the promise that you won’t shy away from them when they arise, that you’ll allow your team to stretch. Great people want a challenge.

After these two values, working with great people on interesting problems, people’s values vary a lot more. Your entrepreneurial vision, potential impact, company culture, work environment, technical infrastructure, decision-making freedom etc. are all really important. But don’t think that they’re enough without a promise of great peers and great problems.

For your first couple of technical hires, of course, you can’t demonstrate the quality of your as-yet-unformed team. The best you can do is promise to engage an outside technical mentor to help you hire  good people, and hand technical hiring over to the development team as soon as practical so that they can control the quality of future hires.

For many potential candidates the first impression they’ll get about working for your company will be a job ad, on your website or elsewhere. This job description (and the rest of your online presence) needs to sell the benefits of working with you. That means you need to sell your talented team and interesting problems, and you need to sell them above your ill-defined vision or potential riches. I’ve drafted up a mock software engineer job ad to help people who don’t know where to start. It’s based on those I wrote for Posse where they were very successful (and Posse’s still always on the lookout for great people). It’s missing a few specifics and anything about company vision and culture will of course depend on the company. But it’s a job ad that I would have been interested in, and aimed at the kinds of people I’ve most enjoyed working with in the past and hope to in the future (stay tuned!).


[Company] is seeking talented and ambitious engineers to help us build the future of [product area].

You might be an experienced engineer with multiple specialties or a class-topping graduate keen to learn while applying your talents to hard problems. At [Company] you will develop creative and innovative solutions to novel problems amongst accomplished peers. We are a small, growing team and you will have a great impact on the design and development of our product. We’re particularly interested if you have [specialty] experience, or are keen to get dirty learning about it.


Our engineers:

  • design, implement and test clear, elegant code (we use [technologies]);
  • work with with other brilliant developers to craft robust systems and beautiful interfaces;
  • sweat the details with product management and designers to implement compelling features;
  • develop tools and processes to continually improve our team’s productivity; and
  • share knowledge, teach, and learn from colleagues.


Our team all:

  • have a passion for developing creative solutions in a team, translating abstract concepts into code, and understanding and adapting to our users;
  • demonstrate strong technical design sense across both the big picture and the devilish details;
  • derive joy from conquering complexity through abstracting, refactoring, and applying well-understood (and sometimes novel) principles and patterns;
  • know how to balance engineering perfection with shipping product;
  • are independent, enthusiastic, and keen to lead talented peers in innovation; and
  • are in-tune with the [industry or vertical].


[Company cultural values or mission]. We release early (daily!) to learn from real users and react quickly. We work end-to-end, so each engineer understands their work in depth. We encourage everyone to learn and share knowledge with others to improve our craft. We exalt engineering productivity and quality and continually improve our tools and processes. We are building a culture and a codebase that are a joy to work in.

[Company] hires only the best and brightest. We offer [compensation and benefits outline]. Other benefits include [more benefits!], plus other random acts of appreciation.

About Company

[Company vision, product outline, challenges]

[Company back-story, market opportunity, notable investors & backers, other evidence of likely impact]


Note this slight tweak to a traditional responsibilities and requirements list: instead of listing desired traits of the applicant, I’ve listed the actual traits of existing staff applicants might work with. You don’t need to be this explicit about it, but in describing applicant requirements a job ad implicitly describes the attributes of your existing or future team, and this is the most important attractor of new talent. This is an ad, the beginning of the pipeline, not an acceptance checklist. Its role is like that of a resume: to get to interview. So sell the experience of working at your company by selling the future peers of successful applicants.

Without getting into details, the ad also makes it clear that interesting problems and challenges exist. With more knowledge your product you can probably be more specific, but details might be better left to a discussion. You should add interesting nuggets of information about your company. Maybe you have some particularly distinguished team members, a unique technical challenge, or some great traction stats. Any of these will help you stand out from other opportunities. And, if you can, add some personality to the mix. Let your company culture shine through. BigCommerce did a great job of this with a Hypnotoad hook, boosting views of their add some by 10 times.

Note also what this ad doesn’t have. There’s no laundry list of specific technical knowledge or experience. There’s a placeholder mentioning what technologies the company presently uses, but you should be looking for people who can take part in decisions about what tools are right for the job. Limiting applicants to specific prior experience is really just limiting your pool of candidates to people who don’t like change. There’s definitely no “N years experience with X” requirement. A flexible team is made of people who learn fast, and you’ll be far better off, a few months down the track, having hired someone who is super-smart and learns fast but has little direct experience with your tech stack than someone who’s been using the same tools for 5+ years and likes it that way. I’ve had this approach validated multiple times by people I’ve hired. Flexibility is super-important when your company is young, so look for smart, motivated generalists over experienced but less-driven experts.

Some other recruitment drives that I’ve been particularly drawn to are those of Asana and Quora. Note the emphases on colleagues, learning, challenges and impact, as well as each company’s mission. Feel the culture of the two companies in the expression of who they want to hire. See how the “requirements”, such as they are, tend to be phrased more like character attributes than specific experience checks. If the teams at these companies live up to these descriptions then they are the kind of people that great developers aspire to be, and will fall over themselves to work with.

I hope that’s helpful for some of you on the hunt for early technical employees. And if the mock ad appealed to you as a developer, well, I’m sure I’ll be building another team like that someday soon.

A scale of ambition

Some four months ago, a Hacker News poster asked YC founder Paul Graham what was the “most frighteningly ambitious idea” he had ever been pitched. I suspect the question arose from an essay PG had previously written by the same title, in which he cites as examples a new search engine, replacing email (been there!), replacing universities, Internet “television” drama, being the next Steve Jobs, bringing back Moore’s Law, and ongoing medical diagnosis. PG withheld his answer, but Eliezer Yudkowsky pitched in with a scale of ambition against which to rank ideas.

This came right around a time when I was consciously practising thinking big, trying to re-calibrate my own scale after some years of employment before considering what I wanted to attempt next. I spent some time and thought tweaking and expanding on Eliezer’s scale, trying to come up with existing companies and new ideas at each level. It’s a logarithmic scale, where each level is a multiple more ambitious than the previous (rather than a constant additive increase). Whether or not you decide to go big, I think it’s valuable to hold ideas up to such a scale for a sense of perspective, the better to weigh the costs and sacrifices of ambition against potential impact.

The Yudkowsky scale of ambition (adapted and with examples by me)

  1. “The next Facebook”
    $10s of billion in value, 100s of millions of people impacted. E.g. Facebook (c. 2012), YouTube (post-acquisition), eBay, Mozilla? Napster? BitTorrent? Kiva?
  2. “The next Apple”
    $100s of billion in value, billions impacted, genre-defining innovation, a worldwide product leader. E.g. Apple (c. 2000–2012), Google (search), Amazon, Wikipedia, Android?
  3. Lead sweeping societal change
    Trigger significant social/political change, economic revolution, etc. E.g. the world wide web, email, mobile telephony, cryptography, nuclear weapons. Ideas: re-invent personal transport (kill cars), revolutionise/decentralise agriculture, a globally comprehensive social learning/knowledge store (Wikipedia x10), replace money/traditional commerce, decentralise communication infrastructure, fully national direct democracy, seasteading, a new country.
  4. Change energy/information infrastructure
    Be the essential enabler of subsequent technological advances, or a massive multiplier. E.g. electricity, radio, the Internet. Ideas: invent/discover “free” energy, transmute sunlight into clean fuel (replace photosynthesis), symbolic telepathy, universal maker-bot, land humans on another planet.
  5. Change the human condition
    Fundamentally change what it means to be human. Ideas: I.Q.-enhancing drug, colonise another planet, replace agriculture as source of food, cure aging.
  6. Change life
    Change what it means for something to be alive. Ideas: Drexler-class molecular nanotechnology, replace food as sunlight→biological energy source, create complex life forms.
  7. Change intelligence
    Change what it means for something to be intelligent. Ideas: upload and execute human brain on a computer, create hive mind.
  8. Create intelligence
    Create intelligence from scratch, shortcutting the entire complexity chain of terrestrial evolution. Ideas: general, recursively self-improving AI.
  9. Hack the universe
    The rules no longer apply to us. Ideas:

The biggest change I made to Yudkowsky’s original is to fold nuclear-like weapons into level three, which was also suggested by HN commenters, reducing the number of levels to nine. For the first couple of levels we can talk about existing and future company valuations as a proxy for impact, but after that it stops making sense as the impacts grow beyond what one company or state has ever captured. Non-profits are interesting to think about at these levels since we don’t have company valuations to help. I’d love to hear suggestions of other existing companies or new ideas in these categories.

So what does your company/project/idea score?

The vast majority of ideas anyone ever thinks about are, of course, less ambitious than 1.0. Rather than define a scale below there I think it’s appropriate just to label a vision as as sane, achievable, orthodox ambitious, and talk about goals for usage or revenue. But remember that it’s merely ordinarily ambitious when evaluating the cost of pursuing it. Or, perhaps, aim higher!

Most change comes from small ideas, built on previous ideas, and executed well. Most of the companies (but not the non-profits) cited above started out that way. There’s no shame, and much honour to be had in pursuing an achievable ambition. Even the largest idea I’ve been thinking seriously about rates a 3 (though I hope to see a few 4’s, maybe a 5 or two in my lifetime). But before it achieves the impact of  a 3, it needs to be a 2, and before that, a 1. And way, way before that it needs to create a little value for a few people, and grow from there. And if that’s all it achieves, it will still be a worthwhile pursuit.


How to find someone technical to build your idea

I’m a mentor in the PushStart collective and incubator. I love the broad exposure to other people’s problems and ideas that mentoring provides and every now and then I discover a team and idea that I really hope succeeds in making our world a better place. At the most recent Mentor Live mentoring event, however, I spent most of my time answering the same basic question over and over again:

How do I find someone technical to implement my idea?

It’s a hard question. People ask because it’s a difficult thing to do. But there are no easy answers: it’s supposed to be hard. Demand for the creativity and talent of great engineers and developers far outstrips the supply. You should have to work hard to convince one to dedicate their time and energy to your project, especially if you don’t have much evidence the effort will be worthwhile (and if you’re looking for someone to build your first version, you have very little evidence that counts).

Developers of all levels of talent have no shortage of ideas and projects to work on. Coming up with a great idea is not the hard part. Some will have their own ideas or side projects, which are pretty much automatically more interesting than yours. Many will field a constant barrage of ideas that naive friends and family bounce around in hope. And the best will have a hard time turning town standing offers to join ex-colleagues in whatever project they’re now pursuing.

So they have ideas galore combined with the skill to execute them. What are you bringing to the table?

Here are two approaches for two extremes.

Group A. You know what you’re doing

You have capital and resources, good networks, experience, strong leadership, deep market knowledge, you’ve tested prototypes and have evidence that what you’re proposing to build is needed. Apart from the knowledge and skills required to actually build a production-ready app, you have everything else covered. Congratulations! You’ve put yourself in a good position; importantly, one where a developer might want to work with you because you’re bringing some value to the team. You’re rare though, so you have a lot of work to do to convince them of this. Ian Crosby has written an excellent answer on Quora (but you already read that before asking me, right?).

Here’s my abbreviated version:

1. Network like crazy

This is lead generation. You need to meet a lot of people to find the one or few great developers who can turn your opportunity into a working product. Get in touch with engineers and developers you already know, go to developer meetups and hackathons (and don’t leave early), reach out to loose connections on LinkedIn, invite nerdy types to your parties, and meet with as many developers as you can. Ask them about their projects, both work and hobby. Get to know what appeals to them. Ask them about people they admire or enjoy working with. Tell them about your emerging business and challenges, ask for their advice. Don’t try to rope them in right away. Build relationships and become known as someone who knows what they’re doing, and is looking for someone great. Follow up with those who seem most interested but make sure they know you’re going to be choosy. Expect this to take weeks to months for you to finally be introduced to a few viable candidates.

2. Choose very carefully

You have a candidate pool, now you need to select the best. Sadly, you don’t have the ability to tell who is a great developer and who is average. If you did, you’d be able to build your app yourself. So find an experienced engineering manager to help. You probably met a bunch over the preceding months of networking: people with broad experience, clearly great at what they do, have hired or been part of hiring A-grade people before, and who draw a lot of respect from everyone else you talk to. You couldn’t convince them to leave their current project but maybe he or she can help you select someone. Ask this person to give technical interviews to your candidates. Be clear about the level of ability, flexibility, technical leadership etc. that you’re looking for. Depending on the strength of your relationship, reimburse them for this highly specialised service. And expect them to reject most candidates.

It’s supposed to be hard, remember? But the good news is that once you’ve found and hired and are working with your first one or two 10x engineers, they will be highly motivated to find and recruit peers who are at their level of ability or better. So long as you let them be picky, you’re on your way to a great team.

Group B. You don’t know what you’re doing

Your idea is awesome. I mean, amazing. Revolutionary, I know. But you haven’t done this before and you don’t have backing to pay a good salary and it’s hard to do customer development on evenings and weekends and you don’t have a prototype or other evidence because finding someone to build that was the whole problem in the first place!

You should fix that before wasting a developer’s time.

Move yourself into group A.


Ideas are cheap and plentiful, so if that’s all you have then you’re not bringing a lot of value to the relationship. There are a whole lot of hard problems involved in building a great product that don’t require deep technical experience, so if it’s not clear that you’re going to have them covered then no-one is going to want to risk working with you. I mean, did you even try asking Google?

And I think that’s the way it should be. Our scarce supply of technical experience and talent must be shared by relatively few projects. If a new project is going to fail for any reason other than lack of developer talent (these days rarely a prime cause) then the opportunity cost, to all of us, of that sunken effort is a great loss. Please don’t waste good developers’ time.

Instead, learn those skills, build your experience, de-risk your business and earn a reputation as someone who does know what they’re doing. Survey and interview customers or users. Gather quantitative data supporting the need for your application. Build and test the business model. Draft designs of your application, test them on people, iterate. Implement a manual MVP of your business. Get someone to help you outsource development of a quick prototype on oDesk or Freelancer.

Prove to yourself and others that you and your idea are worth an investment of development time, talent and creativity. And you might as well start networking with developers now too.