Washington’s incumbent Secretary of State could be doing more to lead on cybersecurity

Respond­ing to Don­ald Trump’s absurd recent alle­ga­tions about elec­tion rig­ging, incum­bent Repub­li­can Sec­re­tary of State Kim Wyman today pub­lished a stern­ly-word­ed state­ment rebuk­ing her par­ty’s nom­i­nee (though not by name) and express­ing full con­fi­dence in Wash­ing­ton State’s own elec­tions systems.

Said Wyman:

In recent days, we have heard heat­ed cam­paign rhetoric about Amer­i­can elec­tions being “rigged” and some­how pre­de­ter­mined. This kind of base­less accu­sa­tion is irre­spon­si­ble and threat­ens to under­mine vot­er con­fi­dence on this most basic foun­da­tion of democracy.

As a twen­ty-four year elec­tion admin­is­tra­tor at the state and local lev­el, with close rela­tion­ships with the nation­al elec­tions com­mu­ni­ty, fed­er­al secu­ri­ty experts and inde­pen­dent aca­d­e­mics, I have full and com­plete con­fi­dence in our sys­tem. Every eli­gi­ble bal­lot will be han­dled secure­ly and will be tab­u­lat­ed care­ful­ly and accurately.

As bal­lots go out this week, I am pleased to note that our paper-based sys­tem cre­ates an audit trail. Our state reg­is­tra­tion sys­tem remains cyber­se­cure and our tab­u­la­tion sys­tems in the coun­ties are air-gapped and not con­nect­ed to the Internet.

We have mul­ti­ple lay­ers of secu­ri­ty, both phys­i­cal and electronic.

Vot­er fraud in the Unit­ed States is con­sid­ered extra­or­di­nary unlike­ly by experts. The vot­ing sys­tem is high­ly decen­tral­ized, with each state, red, blue and pur­ple, run­ning their own elec­tions with a total of over 9,000 elec­tion pro­fes­sion­als who are direct­ly account­able to elect­ed or appoint­ed offi­cials. The cul­ture is that pro­fes­sion­als leave their per­son­al pol­i­tics at the door and treat every bal­lot with integrity.

This is quite true of our 39 tire­less coun­ty audi­tors and elec­tion direc­tors. Our coun­ties oper­ate with full trans­paren­cy and wel­come observers, some even using live web­cams to show bal­lot processing.

It makes no sense that elec­tion man­agers would some­how indulge in a con­spir­a­cy across par­ty lines and state lines.

As with con­cerns about cyber­se­cu­ri­ty, Wash­ing­ton remains vig­i­lant to any pos­si­ble vot­er fraud. Vot­ers should have trust in our elec­tions sys­tem. My hope is that every reg­is­tered vot­er will con­fi­dent­ly cast their bal­lot. We will ensure their bal­lot is tab­u­lat­ed just as they cast it. There will be no rig­ging on our watch.

The paper trail our vote-by-mail sys­tem pro­duces is indeed a great thing, and we’re glad to see Sec­re­tary Wyman denounc­ing Don­ald Trump’s recent comments.

But we have not for­got­ten that she recent­ly called for leg­is­la­tion that would allow her office to con­duct “cit­i­zen­ship checks”. As she says in the release above, vot­er fraud in the Unit­ed States is con­sid­ered extra­or­di­nar­i­ly unlike­ly by experts. We agree, and that’s why we don’t need “cit­i­zen­ship checks” of our vot­er rolls.

Repub­li­cans in oth­er states (like North Car­oli­na, Penn­syl­va­nia, and Wis­con­sin) have used nonex­is­tent “vot­er fraud” as an excuse to ram through vot­er sup­pres­sion schemes that tar­get Demo­c­ra­t­ic vot­ers. Some Repub­li­cans have even admit­ted that the point of these laws are to dis­en­fran­chise voters.

Like Penn­syl­va­nia Repub­li­can Mike Turzai (R‑Allegheny), who boast­ed in 2012, “Vot­er ID, which is gonna allow Gov­er­nor Rom­ney to win the state of Penn­syl­va­nia — done.” (Penn­syl­va­nia ulti­mate­ly sup­port­ed Barack Oba­ma, but the law did cost the Demo­c­ra­t­ic nom­i­nee some sup­port, as Repub­li­cans intend­ed.)

Wash­ing­ton State does­n’t need cit­i­zen­ship checks, but it does need a strong com­mit­ment from its next Sec­re­tary of State to bol­ster cybersecurity.

Kim Wyman’s Demo­c­ra­t­ic chal­lenger Tina Pod­lodows­ki has made this a cam­paign issue. Last month, Wyman’s office put out a press release announc­ing that a “design flaw” in the state’s MyVote vot­er lookup tool had been cor­rect­ed. The release neglect­ed to thank Pod­lodowski’s cam­paign for flag­ging the issue. The “design flaw” exposed vot­er data that isn’t sup­posed to be avail­able to the public.

That par­tic­u­lar issue has been cor­rect­ed, but there are oth­er steps that Wash­ing­ton’s Sec­re­tary of State should take to improve cybersecurity.

Here are sev­er­al rec­om­men­da­tions from NPI.

Force HTTPS on all websites

As a secu­ri­ty-con­scious orga­ni­za­tion, NPI is a pro­po­nent of secure pro­to­cols that encrypt data as it trav­els across the Internet.

One of the most impor­tant pro­to­cols avail­able to us is HTTPS, which uti­lizes Trans­port Lay­er Secu­ri­ty, or TLS, for its mod­ern imple­men­ta­tion. (TLS replaces the now dep­re­cat­ed Secure Sock­ets Lay­er, or SSL.)

Over the past two years, we’ve worked to enable HTTPS on all of the web­sites we main­tain, and route inse­cure HTTP requests to HTTPS instead.

Try to con­nect to nwprogressive.org over HTTP, and you’ll find you can’t — you’ll be upgrad­ed to HTTPS auto­mat­i­cal­ly by default.

The Sec­re­tary of State should fol­low suit, as should all pub­lic agen­cies at all lev­els of gov­ern­ment — local, state, and fed­er­al. At present, HTTPS is not required on all web­sites oper­at­ed by the Sec­re­tary of State. Recent­ly, the main web­site (www.sos.wa.gov) went HTTPS only, which we’re glad to see, but this is not yet the case for many oth­er domains/subdomains the Sec­re­tary of State controls.

Here are some exam­ples of pages/URLs where HTTPS is not yet being forced:

• Novem­ber 8th, 2016 Gen­er­al Elec­tion Results (results.vote.wa.gov)
• MyVote | Vot­ers’ Guide, 2016 Gen­er­al Elec­tion (weiapplets.sos.wa.gov)
• Wash­ing­ton State Archives (digitalarchives.wa.gov)

For HTTPS to be prop­er­ly forced, all images, scripts, and embed­ded media must be served over HTTPS, oth­er­wise mixed-con­tent warn­ings will be generated.

A quick crawl of www.sos.wa.gov by NPI found a num­ber of pages that still have inse­cure con­tent, such as this one, this one, and this one.

Qual­sys Labs grades www.sos.wa.gov as hav­ing an “A” on its high­ly use­ful secure host­ing serv­er test, which is reassuring.

(nwprogressive.org also scores an “A” along with oth­er NPI websites.)

Reset pass­words by hav­ing the user fol­low a link and answer questions

The Sec­re­tary of State’s web­site allows Wash­ing­to­ni­ans to cre­ate online accounts in order to do busi­ness with the office elec­tron­i­cal­ly. For exam­ple, a cit­i­zen may cre­ate an account to file ini­tia­tives online. If you lose your pass­word, it’s pos­si­ble to reset it with­out hav­ing to call up the Sec­re­tary of State’s office.

Unfor­tu­nate­ly, the pass­word reset tool cur­rent­ly sends new pass­words across the Inter­net, unen­crypt­ed, in the body of an email. That’s bad.

Here’s an exam­ple pass­word reset mes­sage that the sys­tem cur­rent­ly generates:

Your pass­word has been reset at. You may login with your email address and pass­word below at http://www.sos.wa.gov/elections/initiatives/login.aspx

Notice the URL above begins with the http:// pre­fix, not https://. Because sos.wa.gov is now HTTPS by default, the user is thank­ful­ly redi­rect­ed and can­not login over an inse­cure con­nec­tion. This used to be an issue but has been corrected.

Email: somebody@example.com

Note that this is a fake email address sub­sti­tut­ed for a real one.

New Pass­word: r3o!OhvUjqr

Note this is an fake pass­word gen­er­at­ed by NPI, replac­ing the one that came in the actu­al email gen­er­at­ed today from the Sec­re­tary of State’s system.

===
Office of the Sec­re­tary of State, Elec­tions Division
520 Union Ave SE, Olympia 98501
PO Box 40229, Olympia 98504
360–902-4180
InitiativeSupport@sos.wa.gov

Mak­ing mat­ters worse, users aren’t prompt­ed to change pass­words once they login, nor is it obvi­ous how to update one’s account infor­ma­tion once logged in using the inse­cure­ly sent pass­word. We rec­om­mend the Sec­re­tary of State do the following:

• Make it sim­ple and easy for users to update their pass­words once logged in. For exam­ple, on the ini­tia­tives por­tal, there should be a promi­nent links to Man­age My Account / Update My Pass­word on the My Fil­ings screen, and every oth­er screen a user sees while logged in to the system.
• Send users a link to change their pass­word and put that in the body of the email instead of send­ing the new pass­word in the body of the email. The link should expire after twen­ty-four hours or less. The new pass­word should be cho­sen by the user and should meet min­i­mum com­plex­i­ty require­ments. Punc­tu­a­tion should be allowed and encour­aged in all passwords.
• Require users to set up answers to a set of secu­ri­ty ques­tions and pro­vide the cor­rect answers to at least two of those ques­tions before allow­ing the account pass­word to be reset. Ques­tions like “What is your moth­er’s maid­en name?” should be avoid­ed. Ques­tions like “What is your favorite vaca­tion spot?” are more appro­pri­ate. Users should also be able to cre­ate their own ques­tions. Users who can­not answer the secu­ri­ty ques­tions should be prompt­ed to call the Sec­re­tary of State to unlock their account.

Hard­en web applications

Like NPI, the Sec­re­tary of State’s office uses soft­ware such as Word­Press to man­age con­tent. By doing some quick inspect­ing of the web­site’s source code and prob­ing for README files, I was able to learn a lot about the soft­ware the site is run­ning, includ­ing plu­g­ins, and what ver­sions of that soft­ware are cur­rent­ly in use. This could be valu­able infor­ma­tion to some­one try­ing to break in.

For secu­ri­ty rea­sons, I’m not going to elab­o­rate any fur­ther in this post regard­ing what I found, as I believe in prac­tic­ing respon­si­ble disclosure.

NPI rec­om­mends the Sec­re­tary of State take steps to hard­en its web appli­ca­tions to guard against unwant­ed intrud­ers. Steps that should be tak­en include tight­en­ing per­mis­sions, enabling defens­es that can thwart and deflect brute force attacks, and pre­vent­ing plu­g­ins from embed­ding HTML com­ments in web page source code.

Imple­ment Con­tent Secu­ri­ty Pol­i­cy and XSS protection

For bonus points, the Sec­re­tary of State’s office ought to begin work­ing on imple­ment­ing Con­tent Secu­ri­ty Pol­i­cy across all of its websites.

This is some­thing we’re start­ing to work on at NPI, to take our sites’ secu­ri­ty to the next lev­el. It’s done by set­ting serv­er headers.

As Mozil­la’s wiki explains:

Con­tent Secu­ri­ty Pol­i­cy (CSP) is an HTTP head­er that allows site oper­a­tors fine-grained con­trol over where resources on their site can be loaded from. The use of this head­er is the best method to pre­vent cross-site script­ing (XSS) vul­ner­a­bil­i­ties. Due to the dif­fi­cul­ty in retro­fitting CSP into exist­ing web­sites, CSP is manda­to­ry for all new web­sites and is strong­ly rec­om­mend­ed for all exist­ing high-risk sites.

The pri­ma­ry ben­e­fit of CSP comes from dis­abling the use of unsafe inline JavaScript. Inline JavaScript — either reflect­ed or stored — means that improp­er­ly escaped user-inputs can gen­er­ate code that is inter­pret­ed by the web brows­er as JavaScript.

By using CSP to dis­able inline JavaScript, you can effec­tive­ly elim­i­nate almost all XSS attacks against your site.

Replac­ing inline JavaScript is cer­tain­ly not sim­ple or easy to do — it takes work. But imple­ment­ing CSP leads to secur­er web­sites. We intend to do it, and we urge the Sec­re­tary of State to com­mit to doing it as well.

X‑XSS-Pro­tec­tion can and should be imple­ment­ed in the mean­time to pro­tect users who use Inter­net Explor­er or Chrome/Chromium.

The rec­om­men­da­tions out­lined above, inci­den­tal­ly, are rec­om­men­da­tions that we would urge every pub­lic agency every­where to adopt.

But because the Sec­re­tary of State’s office is respon­si­ble for so much vital record­keep­ing, coor­di­nat­ing with Wash­ing­ton’s thir­ty-nine coun­ty gov­ern­ments, it should be a cyber­se­cu­ri­ty leader, set­ting a good exam­ple for all to follow.