The html input tag is what’s used to display a text box on a Web page. Input has an optional type parameter. Specifying type="password" causes characters to be masked, an asterisk is displayed instead of the character typed. It’s standard practice on the “big” web to to use type=”password” on any field where the user enters a password or PIN.
This practice has been carried over to the mobile Web were I think it hurts usability while doing little or nothing to enhance security.
Of course, security on the web is real concern. Phishing and identity theft are constantly in the news. For eCommerce and banking sites I’m willing to put up with a little inconvenience in the name of security. But does masking the password of, say, an online RSS reader really make us any safer? What’s the worst that can happen, someone marking all our feeds as read?
Phones have small screens and correspondingly small fonts. It’s hard to read a mobile screen from a distance of more than a couple of feet. If your worried about password theft, you can usually turn away from onlookers or shield the screen with your hand while entering your password. I think there is a far greater likelihood of a bad guy stealing you password by watching which keys you are pressing than by reading the screen.
Mobiles generally show you the actual character for a fraction of a second before it changes to an asterisk but It’s still hard to accurately triple tap passwords on a phone. It’s especially difficult if you use “strong” passwords with a mix of upper and lower case letters, digits and symbols.
What do you think, do masked password fields on mobile web pages actually enhance security? And even if they do in some small way are they worth the cost in usability; especially on sites where there’s no risk of financial loss?
How i resset my passward in my account for binu
@exodusmulu – I have the same problem. I have not used Binu for quite some time, now I have forgotten my pin, and urgently need to use it. I keep on pressing ‘what is my pin’, and they keep on saying ‘your pin has been sent to your phone via sms’, but I never get it!!! I cannot delete my account & get a new one, because I cannot get inside the account to do it…grrr!!!
@Dennis – ‘Binu’ is an application wich contains hundreds of apps in one – you can choose wich ones you want on your home page. One of it’s main cool features is ‘Binu Messenger’, from wich you can Email + IM (to other Binu users) for free, as well as send free sms’es to any cell number (even if they don’t have the app. You get 10 free credits per week, and 160 characters = 1 sms. You can also buy more credits.
I use binu on my phone my phone number is [removed] but I can’t get my pin or can’t reach to my phone please send it by my email address
I don’t know why you think I would know what your PIN is but I don’t. I don’t know what “binu” is either. If you haven’t changed the PIN, it’s usually printed on a card that came with your SIM, If not contact your operator they are the only ones would can provide or reset PIN and PUK codes.
Also posting your phone number on the public web like you just tried to do is dangerous and can result in scams that will steal your prepaid credit or run up a huge bill if your on postpaid.
Whenever I build a mobile site that needs a password, I use a 4 digit PIN. The only thing more annoying than typing out a word on a feature phone, is doing it with asterisks.
If a 4 digit PIN is good enough for my bank account and a public ATM, then it’s good enough for a mobile phone. Less chance of someone seeing that then an ATM keypad or screen.
I set the field to digits only, and log on is quick and simple.
As for finding other ways Luca, you and I know quite well that there’s an issue there. If all the carriers in the world want to pass a unique ID, I’m all for it. It would make our tracking through Mobilytics much easier as well. Other than that, we’re still dealing with hundreds of different browsers and non-standard capabilities.
Greg Harris
Pingback: links for 2008-05-30 :: User First Web
It doesn’t matter. What matters is that throughout your website, you must be consistent. Some handsets will change the input mode if they encounter type=’password’. So once you have made the decision to use password or text, make sure you do the same thing everywhere.
Pingback: Carnival of the Mobilists #125
I really think that is unnecessary…
but, I already saw people that think that writing at passwords fields with *** is more safe…
I agree with teroff ideas, it’s depends on the situations and the people who are using.
Love these posts that go into the real nitty gritty of mobile usability … logging in on mobile sites is a real issue as it is such a pain. Agree that showing the password instead of **** would be a step forward but is it enough? Should we focus on alphanumeric passwords for mobile or something?
…we were just discussing this internally the other day Dennis. Thanks for bringing it up you and Luca helped me to push the vote in favor of removing password masking. :)
I’ll get the ball rolling by providing my opinion.
According to the GAP mobile development guidelines (which are better than the W3C BP committee-designed nonsense), developers should ask themselves whether the security requirements for their applications are really so strict that making the password hard to read isn’t punishing the legitimate users too.
There is a GAP rule called NO_PASSWORD_MASK that reads:
———
Do not use password masks
Reading what is on the screen of a mobile device is often hard enough for the user of the device. Peeking over the shoulder of the user is less likely to disclose a password than observing the user’s keypress sequence.
For this reason, hiding user input to users themselves by replacing each character with a ‘*’ (star) symbol (or similar) will do very little to protect privacy, while making it generally harder to use the service. For this reason, users should be made enter passwords in clear text.
This practice does not detract from the aforementioned practice to avoid login and find alternative ways to identify users.
Caveat: In case of highly sensitive application (such as ‘Net Banking’), security requirements may force you to overlook this practice. For example, some users may perceive the lack of password obfuscation as a sign of slack security practices.
———
if someone disagrees with this, please let me know: happy to discuss
Luca
Hello, first of all, thank you for this site. It’s really interesting and helpfull blog.
If we say about password on mobile web portals, and using type=”password”, I would say: “It depends…” It depends on the situation and on the people who using this mobile portal.
And I think that Pohones must have one cpecial function wich will be on of off using type=”password”
P.S. Sorry for my English, I’ve just learned
You make a good point that I’m sure most people overlook because, as you’ve mentioned, it’s almost customary to use this convention.
I think it’s definately NOT worth the cost in usability – especially with phones that don’t support full qwerty…
The only issue I see though is the concept of ‘One Web’.