(engineer attention) password not obscured on login

I noticed at work today on a slow Dell operating firefox I had similar issues L2R.
 
IF the problem can't be fixed, i'd suggest the log on boxes be completely delayed, meaning not visible until the screen is fully loaded.
 
^^ I agree, it worries me. We have had account hacking in the past, is it even possible someone has hacked VB and done this to access users passwords.
 
Well, this is most disappointing.

I honestly don't know what the issue is at the moment.

Until we can isolate the problem or determine whether this is a product-level/skin issue, I can only advise that you wait until the page loads completely before entering your details.

Either that, or stop contravening your workplace's Internet policy by browsing drug websites. ;)

Any further information on when this started would be appreciated.
 
It's still working fine for me on my home network.

I just tried coming to BL with a proxy that would significantly delay load time. What L2R described happened with my Username, but the PWD could still be entered privately (even before the page loaded, when the Username field was still acting up).
 
I did. I have no clue.

15rf4i0.jpg
 
^ That image looks like it's been compressed (the distance from login box to advanced search should be far greater).

Is that a direct screenshot or have you adjusted it to keep the size down?
 
Last edited:
It's direct, but the program I was using to proxy-surf compresses the page.
 
My understanding is that the credential input form is coded as an <input=password> type. Meaning that, by default, your password will be obscured when entered - just like any other password entry form.

However, from what I can gather, vB runs some javascript that changes the input type to 'text' rather than 'password'. This allows the system to show the greyed-out/dismissable prompts of 'User Name' and 'Password' instead of ●●●●●●●● in the fields when the page loads. I suppose somebody, somewhere thought this was progress.

When the field gains focus (by you clicking on it), the system will switch its type back to password and your username will overwrite the prompt and your password will be obscured. However, you guys appear to be experiencing some sort of issue where the javascript is supposed to change back to a password field on focus, but is not kicking in in time.

The fact that the Google CSE helped solve some people's problems is interesting, but I cannot see an immediate solution to this problem - especially considering that it's restricted to a small number of people on sluggish networks, that we have not identified how long this has been going on, that I cannot identify what (if any) changes that have caused it, and that I'm struggling to replicate the problem.

I might advise that you turn off Javascript completely while at work. The password field should work properly, although the username field will probably require deleting before entering your handle.
 
best advice would be to (as always) ensure no-one's looking over your shoulder.

I am assuming there is no actual security concern here with Blueliight. right?
 
tambourine-man said:
My understanding is that the credential input form is coded as an <input=password> type. Meaning that, by default, your password will be obscured when entered - just like any other password entry form.

However, from what I can gather, vB runs some javascript that changes the input type to 'text' rather than 'password'. This allows the system to show the greyed-out/dismissable prompts of 'User Name' and 'Password' instead of ●●●●●●●● in the fields when the page loads. I suppose somebody, somewhere thought this was progress.

When the field gains focus (by you clicking on it), the system will switch its type back to password and your username will overwrite the prompt and your password will be obscured. However, you guys appear to be experiencing some sort of issue where the javascript is supposed to change back to a password field on focus, but is not kicking in in time.

The fact that the Google CSE helped solve some people's problems is interesting, but I cannot see an immediate solution to this problem - especially considering that it's restricted to a small number of people on sluggish networks, that we have not identified how long this has been going on, that I cannot identify what (if any) changes that have caused it, and that I'm struggling to replicate the problem.

I might advise that you turn off Javascript completely while at work. The password field should work properly, although the username field will probably require deleting before entering your handle.
Click to expand...

I am by no means on sluggish internet... If I was to download a program it would download at approximately 1.5mbps...

Also FWIW when I managed to log in, after the password I entered (my real one not the fuckyouBL one) the dots changed back to saying fuckyouBL but it still logged me in
 
tbph i couldn't care less if my bl gets hacked. this is for those who have a lot at stake in their anonymity here, something i think which is not that uncommon for the type of site this is.
 
tambourine-man said:
My understanding is that the credential input form is coded as an <input=password> type. Meaning that, by default, your password will be obscured when entered - just like any other password entry form.

However, from what I can gather, vB runs some javascript that changes the input type to 'text' rather than 'password'. This allows the system to show the greyed-out/dismissable prompts of 'User Name' and 'Password' instead of ●●●●●●●● in the fields when the page loads. I suppose somebody, somewhere thought this was progress.
Click to expand...

Just a crude theory, but...

function changefieldtype()
{document.getElementById("pwd").innerHTML = "<input type=\"password\" ... />";}

<div id="pwd">
<input type="text" onfocus="changefieldtype();" value="Password" ... />
</div>

That would allow "Password" to be shown as a default text value until the user clicks inside of the password box, when the JS function changefieldtype() converts it to a password type with ●●. It should happen almost instantaneously.

The window object in JavaScript has an event-handler called onload, which executes its functions after the entire pages has completely loaded. Sometimes functions are placed at the bottom of <body> so that they load later. Delay is typically used for things like alerts or modifications, which can fuck up a rhythm if executed before everything on the page has loaded. If the above function changefieldtype() happened to be delayed for any reason, it would not be able to be executed until the page had been further loaded, meaning that one could still type text into the password box until the page had further/completely loaded. This seemed to really be the case when the GSE was still around, but still could be as long as there's enough to stretch out loading.

The bad news would be that if it's anything like this, it's a vbulletin issue and would require at least a new skin to try and fix.

If you're worried about security here, the beyond-simple solution is to just wait the few seconds until the page loads before you type your PWD. Type a fake first letter to see if it's changed yet.
 
Last edited:
^

I can't respond fully at the moment due to time constraints, but your theory is similar to my understanding - although I think the password field is actually coded as "type=password" as default, and the JS converts it to "type=text" on load, and back to "type=password" on focus.

The username field, I'm not sure about.

Thanks for taking the time to make some suggestions. I'll look into it and raise with our engineer if I can't find a resolution.

What isn't clear to me, at the moment, are two things:

Why this only effects a small number of people?
Why (or if) this has occurred spontaneously, or if it's been going on for longer unreported?

In terms of security... I tend to agree. The risk appears to be minimal and can be mitigated by simply being careful who is around you when you type your password in.
 
How many of you are using proxies or browser plug-ins?

How many people are on a network that places restrictions on scripts?

Might be worth trying the log-in procedure with a direct connection and plug-ins disabled.
 
tambourine-man said:
I think the password field is actually coded as "type=password" as default, and the JS converts it to "type=text" on load, and back to "type=password" on focus.
Click to expand...

That is the dumbest thing I've ever heard. That developer must have been on illegal drugs or something. He should be taken out back and shot. :D

I'll take your word for it that it instantiates as type=password and changes twice. I just, honestly, wouldn't think that vBulletin would do something that poor on such a big product.

Why (or if) this has occurred spontaneously, or if it's been going on for longer unreported?
Click to expand...

Server-side javascript changes? I dunno.

tambourine-man said:
Might be worth trying the log-in procedure with a direct connection
Click to expand...

COPS! COPS! I knew something didn't feel right...;)
 
Last edited:
not enough privilege at work for such uber 1337 gibson hackage
 
this was better for a bit, but then as of last week it got worse.
 
You must log in or register to reply here.
Top