On the HTML input form element, you must define a type and may define a maxlength attribute. This is in regards to the password type and the relation it has to the maxlength attribute. If the maxlength on a password input is wider than the width of the input, there is no way to tell if what you are typing (or pasting) is actually going into the field.
Below are two test forms that will illustrate my point. Each form looks identical, but have much larger implications in practice. Test the following KeePass generated password in the following forms:
What you have just experienced is a problem that exists on many website’s user registration. If this were a real user registration, the password you entered will not completely save and you will be locked out when attempting to log in. This happens when sites validate the length of the password by specifying a maxlength as opposed to correctly checking its length during the form processing. Overall, using client side markup to validate form values is precarious. Therefore, maxlength should be limited to text input types, if it is backed up by server side validation.
P.S. Stop putting maximum length requirements on passwords, period. Just hash the password and store that. And no, password retrieval is not an excuse; have the user reset their password instead.
Most women who have been on these sites have at least one story of a guy sending some ridiculous email with an incredibly offensive suggestion or perhaps an indecent picture attached.
A strategy to mitigate the effects of these creeps is two fold; first, identify these profiles, and second, prevent these profiles from continuing to creep.
An option for the first part would be to create a “creep trap”. Ideally, this would be a profile of a fictional woman with attractive pictures and a generic profile. Messages sent to this profile would then be scrutinized for their quality. If they contained ads, an over the top request, or are written like a text message, the senders profile would be flagged.
As for the second part, I do not think this is taken advantage enough in services such as these. Some sites are diligent and do ban troublesome users, but with the internet it is easy enough to create another profile. Instead, the site can quietly sandbox the user. To them it seems as though their emails are being sent; though, in reality, they are deleted and their profile is not viewable by anyone else.
The specifics of how many creep emails over a period of time should cause a user to be sandboxed is up for discussion, as well as sandbox duration. Overall, I would imagine this would amend the creep problem as well as improve user confidence.
The term ‘load-bearing code’ can be used to refer to software that exhibits the following attributes.
- Has no documentation or automated tests
- Written by an ex-developer
- Used by a large portion of the code base
- Supports critical system processes
This term was inspired by its memorable use by Cosmo Kramer in the Seinfeld episode “The Chicken Roaster”: Jerry, these are load-bearing walls, they’re not gonna come down!
I have encountered load-bearing code from legacy open source applications, inherited projects or debugging production software.