The Nevada, Indiana, and Florida DMVs have unusually bad login pages.

I spend an unreasonable amount of time thinking about login pages. To be fair, I pretty much sell login pages for a living – our company Tesseral builds auth software – so I have to know what good looks like. But that means I also need to know what bad looks like.

In the spirit of finding some suboptimal login pages, I visited the websites for each state’s Department of Motor Vehicles or equivalent. Here are the worst ones, in my opinion. (I also give credit to some good ones at the end.)

Bad login pages

Indiana

First up is the Hoosier State, which hosts its Bureau of Motor Vehicles web app at https://mybmv.bmv.in.gov/bmv/mybmv/default.aspx. A fun fact about Indiana: the state experienced its Golden Age of literature from 1880 to 1920.

At first glance, this website appears positively ancient.And it really is ancient. I don’t know much about old school web development, but I can see that it returns an old-looking resource.js to me that worries about Netscape, which hasn’t been a thing in a very long time.

function getKeyChar(e) {

    	if(window.event) // IE
    	{
    		return String.fromCharCode(e.keyCode);
    	}
    	else if(e.which) // Netscape/Firefox/Opera
    	{
    		return String.fromCharCode(e.which);
    	}

    }

Now, I’m not against old tech. There’s no reason that a DMV website needs to be using the latest hype-y Javascript framework. But I can’t help but notice that some things are broken. For example, the print button in the upper right only works sometimes (mostly when I first visit a page).

I’m not sure exactly why it fails. Let me know if you can figure it out.

You may also notice the banner at the top of the page indicating that the system goes down every Sunday morning for five hours. That’s a pretty meaningful chunk of time!

The auth system makes me feel uneasy. In fairness, I didn’t really test the thing – as I don’t live in Indiana and don’t want to do fraud – but I don’t like that the Forgot Password flow starts with a request for a driver’s license number and the last four digits of my SSN. For a nefarious actor, this stuff isn’t too hard to guess. And I kind of doubt there’s any email verification, let alone multifactor authentication, going on here.

Overall, not the best! I give it a 21 / 37.

Nevada

In the process of becoming a state in 1864, Nevada sent its constitution to Washington over telegraph. It was the most expensive telegraph on record at the time, ringing in at around $4,500 in 1864 dollars. That’s over $100,000 in today's dollars. Pretty neat, right?

Onto their DMV login page!

It’s hosted at https://dmvapp.nv.gov/DMV/Application/DMVPortal/Pages/Default.aspx.

Right away, this page has some weird stuff going on. It has a few buttons toward the top of the page – looking like Home | Records | Recent Activities | My Account | Contact DMV | Logoff. It’s probably because I’m logged out, but none of these buttons work properly.

Only the Logoff button does anything. It opens up a modal that requests confirmation. When you confirm yes, I want to log off, you get redirected to a totally different web app. You’re no longer on dmvapp.nv.gov, but instead on dmv.nv.gov. That’s not a huge deal, but it’s still kind of weird.

The create an account flow also seems a bit worrisome to me. As a new user, you have two options when you log in: either you supply your social security number or you pick three security questions.

As for the security questions… I don’t really like security questions in general, but these are especially easy to guess. They don't do much for security. Here are some of the options:

• What phone number did you provide to the DMV?
• What state was the license from that you surrendered to the DMV?
• What was your previous Nevada address?

As far as I can tell, Nevada neither verifies emails nor enables multi-factor authentication.

It seems like the password requirements are pretty weird too. Your password has to be exactly eight characters, and it’s somehow not case sensitive. Yeah -- exactly eight. Not case sensitive. Some very surface-level research suggests this was a real constraint for certain IBM systems a long time ago, but come on. (Here again, if you're acquainted with the technical constraints at play, please let me know!)

Not good, Nevada. I rate it a 13 / 37.

Florida

Fun fact! The highest point in the Sunshine State is Britton Hill -- just 105 meters above sea level.

Now let’s look at Florida’s DMV login page.

I wanted to give Florida credit for social logins. They show options for Twitter, Google, and Facebook OAuth -- a really great start.

But they don’t work … at all. I wasn’t able to get any of these social logins to work properly. Going through the auth flow for Twitter, I ended up with an unable to obtain request token error in my query parameter.

The Facebook login button did send me to Facebook … which alerted me that “this app is not accessible right now and the app developer is aware of the issue.”

The Google login button didn’t redirect me anywhere the first time I tried it. I came back later and did end up going to Google, which merely identified the Florida myDMV app as “Salesforce.” I got an opaque error from Salesforce: “We can’t log you in because of an authentication error.”

A possible hint in the Network tab:

https://mydmvportal-flhsmv.my.site.com/_nc_external/identity/sso/ui/AuthorizationError?ErrorCode=REGISTRATION_HANDLER_ERROR&ErrorDescription=Attempt+to+de-reference+a+null+object&ProviderId=0SO1R000000L1J5&startURL=%2FHSMV_confirmEmailPage

Some kind of custom Salesforce Apex code looks like it’s referencing a null value? This doesn’t seem like an edge case to me. This is just not good.

Also, hold on. Why is the Florida myDMV login portal built on Salesforce? A major consumer-facing website using Salesforce for authentication is pretty odd. I get that you can make Salesforce do basically anything, but I haven’t seen someone do this before. There are much easier ways to build authentication into a web app!

Florida didn’t even move this off a Salesforce domain. It’s on my.site.com and has a SFDC favicon. It’s kind of hard to trust that this is a real government site, especially because the FLHSMV logo has such low resolution.

Two years ago on Reddit, a user asked, “is the Florida DMV website just fundamentally broken?” It seems like nothing has changed.

I rate it a 17/37.

Dishonorable Mention: South Dakota

Did you know you only have to stay in South Dakota for one night to be considered a resident? Weird, right?

Let’s look at their DMV login page.

I’m cheating here a little bit, because to the state’s credit, it does seem like they’re migrating onto a centralized auth service across state agencies. However, the old school mySDCars app is still the top search result and therefore feels like fair game for a dishonorable mention.

The banner at the top warrants mention first. It wants the user to visit a specific URL. Oddly, though, it gives the URL as plain old <strong> text. Why not simply redirect the user? Why not make it a clickable link? I didn’t even notice the banner was there until I’d clicked around a bit.

It’s quite odd to me that the login button still works. As far as I can tell, it does still hit a backend somewhere. Can you still log in? I wish I knew. I have never had an account. (And, as with other sites here, I was not interested in testing the site too much; I was genuinely worried that I'd break something.)

The Create your Account button is greyed out with a tooltip inviting certain users to Contact DMV using a link in the footer. That link 404s.

Mostly, though, this page is just kind of ugly.

The state deserves some credit. It looks like the slow march toward a centralized login portal for all South Dakota state services is underway. Moreover, it looks like they might be using Azure Active Directory B2C – excellent work by the SD BIT picking something sensible off the shelf.

Good login pages

I don’t want to be too negative, because quite a few states actually get this stuff right. Here are three that I think are pretty solid.

Ohio

Ohio’s BMV has a great login page. They correctly recognize that some activities require tighter identity controls than others. You can do most things on the site as a guest, but you need to log in to change your address or reprint your driver’s license.

Authentication with the BMV relies on a centralized system shared among Ohio’s state services: OH|ID. Citizens keep one account that confers access to all state services. Signing up requires email verification and configuration of password recovery options. Logging in always requires multi-factor authentication. Overall, it’s a nice system.

The site even includes a banner emphasizing that state websites always use ohio.gov. It seems trivial, but this is an easy way to deter phishing.

Good work, Ohio!

Connecticut

Connecticut’s login system works pretty similarly to Ohio’s. It’s a centralized service across state services. It requires email verification. Nice! While Connecticut doesn’t require multi-factor authentication for everything, it does emphasize that some more sensitive actions will require MFA. I think that’s a reasonable place to land.

New York

New York has a pretty similar system. They centralize logins across state services. One thing that’s kind of neat: the same general system drives authentication for citizens, government workers, and businesses alike.

Someone on Reddit did complain, “My.ny.gov is the worst thing the state ever created.” So it’s clearly not perfect. But man – it’s doubtlessly better than some of these other systems.

Conclusions!

I’ve been told that I can’t just end blog posts when I feel like I’m done and that I need to add a conclusion.

A few ideas for folks responsible for authentication:

1. Consider deprecating old systems. There’s no good reason in 2025 to be holding together an ancient web app with bubble gum and duct tape. It’s hard to make changes, yes, but it’s also hard to keep brittle old legacy code running safely. You shouldn’t be forced to use low entropy passwords like Nevada. Instead, be like South Dakota – get rid of the fragile thing that requires downtime every weekend.

2. Don’t do weird stuff. If you have pretty vanilla requirements, consider using a cloud service provider and move on. If you’re determined to build something custom, use a normal open source tool like Keycloak or a library like Devise. Unless you’re running a service at crazy scale – like Facebook – you should just try to do what other people are doing. There’s no reward for creativity in authentication.

3. SSO is good! If you can minimize passwords, you probably should. At minimum, don't let people use bad passwords.

4. Add email verification and MFA. I know people don’t like it, but you really need to be adding MFA to government websites. Even SMS MFA is worth something.

5. Take the opportunity to deter phishing. Put stuff on an authoritative domain (e.g., a .gov). Use high resolution images. Get rid of typos when you find them. You really shouldn’t be training your users to enter their passwords on random sketchy websites with inscrutable domains. Eventually, someone will take advantage.

About Tesseral

Tesseral makes open source auth for SaaS applications. We're not going to help state DMVs overhaul their login pages, but we can make life easier if you make business software!