Opera doesn't 'forget' my router password!

Hi all. When using other browsers on any of my Windows XP SP3 systems I am prompted for a password every time I try log in to my router web configuration page (e.g. http://192.168.0.1) or attempt to 'apply' settings after the auto-timeout value has been exceeded.

When using Opera v11.52 (build 1100) I only ever get prompted for the router password once per session, and for the remainder of that Windows session I/anyone can freely access the page using Opera without needing to supply a password - which is plainly a huge security risk!

How do I force password prompting each time I log onto my routers config page (Billion 7401VGPR3 with v6.23 firmware) and force it to honor the auto-timeout? And more to the point, why does Opera behave as it does by default?

Password manager is enabled but I have not asked Opera (or WIndows for that matter) to save/remember the password in question (and it's not listed in the password manager). While I can force Opera to reprompt for a password by deleting all protected pages/data (using Tools -> Delete Private Data -> Delete password protected pages and data) I can't work out how to automate that process or specify which pages to delete (i.e. only the router related data), and in any case that doesn't help with Opera ignoring the auto-timeout.

I've tried to like Opera despite its many quirks but this issue is a deal-breaker for me, and if all Opera installs behave like this "out of the box" I have no choice but to actively block installation of Opera on all the systems I manage.

Any ideas what's going on? Has anyone else experienced the same problem?

Thanks in advance, Nick.

I've just retested with a fresh download/install of Opera 11.52 Build 1100 and still see the same behaviour, i.e. having logged onto my router via Opera once I can freely log in again (with Opera) during that Windows session after exiting the initial instance (something both IE 8.0.6001.18702 and Firefox v3.6.22 rightly don't allow by default on the same system).

I've again tried searching for a solution both on these forums and elsewhere and have not found a thing beyond an old reference to "Use cookies to trace password-protected pages".

Does anyone here want to hazard a comment on this issue? It would be helpful if someone could at least confirm it's not a problem on their system.

Does this "auto timeout" means "auto logoff"? Where did you set it?

If i went to my router's config page on IE, it will remember username and password until i close the browser. But my router does not have this timeout thing.

I have this problem too (with a Netgear N150). Bugs me, but I haven't investigated it yet.

Originally posted by LeoCG:

Does this "auto timeout" means "auto logoff"? Where did you set it?

If i went to my router's config page on IE, it will remember username and password until i close the browser. But my router does not have this timeout thing.

My bad, yes auto-timeout == auto-logoff, and it's a router setting (typical on "security routers"). With the Billion models I use it's set via Configuration->Device Management->Expire to auto-logout (in seconds).

Using Opera's scripting error console I can see a few errors thrown on the Billion pages but they all seem to be ignorable style issues with the html; there's no indication any supporting scripts are failing to run. I had presumed until now the OS was responsible for processing "protected pages" (an easy enough impression to form given IE/Windows integration) but it seems they're handled entirely by the browser, and of those I've tried on my XP system, latest IE8, FF and Opera, only Opera doesn't time out when the set number of seconds has elapsed.

Originally posted by burnout426:

I have this problem too (with a Netgear N150). Bugs me, but I haven't investigated it yet.

Thanks for that feedback. With no other system/router to test atm I was left wondering whether the issue was isolated to my system components or not, and your post suggests it's not.

Caught between a want to warn others of a potentially very serious security flaw and not wanting to spread FUD I planned to ask someone with Opera on the Billion forums if they were willing to test this behaviour for me/us but my sign up still hasn't been processed (I guess they meant "within 10 Microsoft minutes" ). I'm glad in a way as it would make more sense to have that testing conducted here - I'm hoping others on these boards might also chime in with their findings, if only to confirm this as a 'bug' with Opera and allow it to be passed it on as such to the developers.

I checked my issue. The netgear logout page is broken (in all browsers, even IE).

The source of the logout page uses top.close() in a script to just close the tab (which doesn't work in Firefox by default because of a security restriction). There is a form in the page that posts to logout.cgi. But, it's never submitted in any way in any browser.

I'm basically seeing this <http://forum1.netgear.com/showthread.php?t=55514>. Netgear told them "The browser maintains a connection until that browser session ends apparently."

Thanks for that info burnout, I have a WNDR3700 I plan to add to my home network (for an isolated wireless only subnet) so will remember to check if the same/similar issue exists with that model when it's hooked up.

The Billion issue is different in that, of 'the Big 3' I've tested so far, only Opera doesn't behave as expected with regard to timing out during a given browser session. That doesn't necessarily mean the fault definitely lies with Opera (and not Billion) but it's a reasonable assumption to make at this point, though I admit I lack the smarts to properly analyse the interaction between Opera and the router to confirm that myself.

The bigger issue of course is with how Opera appears to retain (a pointer to) the supplied form input until Windows is rebooted. Again, I don't want to beat a drum but I won't shy from saying if that's done 'by design' it's at best a patently ignorant design and should be revised at the earliest opportunity.

If you didn't try already, you should add a site preference for 192.168.0.1 and set Opera to mask as firefox to see if it helps. Even router pages have bad browser sniffing sometimes. I don't necessarily think it's going to help, but you can rule things like that out.

I hadn't, but just did, and found your hunch spot on - after using Preferences->Advanced-Content->Manage Site Preferences to add [something like] 192.168.0.1, selecting Mask as Firefox then restarting Opera I'm now re-prompted when trying to access the router. Still once only for that browser session (i.e. it's still not timing out) but that's certainly a great start.

I and 'Billion's of others (couldn't resist sorry ) owe you a big thanks. I'll chase down my Billion registration to post these findings as a bug with them and hope to post back soon with their response.

Cheers, Nick.

Hi Nick

This issue has been fully checked & confirmed by Engineers, the problem is with browser/caching, some have more problems than others with this, suggest that you try a different browser.

Regards
Billion Support Team

I don't know where to turn from here. We use Billion modems at my workplace and the network admin now refuses to allow Opera to be installed on any system directly connected to those devices (and are working on actively blocked Opera downloads and installs with TMG). I also use a Billion, and I'm prepared to persevere with Opera for the moment (though on my system only for now), but I would hope someone - and that looks like the Opera dev team at this stage - comes to the party with a proper solution to this issue.

I marked the Billion ticket as 'high priority' because I truly do think any backdoor into a router (which is how I view this) is a huge security risk. I appreciate Billions stance on the matter but I'm not entirely happy with the response (though I'm still having hassles with the forum registration so am unable to discuss the issue there yet).

Despite it being unlikely to bite for most it's a flaw that's trivial to exploit and frankly that makes a mockery of any genuine claims of 'security' in my opinion - sure *I* (and those who are aware of the issue) can secure my systems somewhat now that I know the workarounds (delete all protected pages on exit, or add 192.168.x.y and mask as FF/IE) but by default the combination is most definitely insecure - consumers should NEVER be put in a situation which potentially boils down to 'own my browser and you also own my router'.

Work beckons; I hope to talk more on this point later and again would like to hear what others think about this matter. Is this an overreaction from a few paranoid users, or a serious security flaw that *someone* should pull their finger out and fix?

If you open a private tab and only log into the router in that tab and close out of that private tab when you're done, it should work much better, even if you then open another private tab.

You could also launch a separate Opera just for logging into the router. Then, always close that Opera when you're done.

Those might not be good enough solutions for your workplace though.

Also, just to test, goto opera:config#cache and try checking "Always Reload HTTPS In History" or "Always Check Redirect". You could try unchecking "Cache HTTPS After Sessions" (even though that shouldn't help).

Undert "Ctrl + F12 -> advanced -> history", you could try turning off the memory cache or setting "check documents" to always". Something might work.

Those would all affect normal browsing, so it might not be a good solution, but it'd be good to know if any of those help.

Thanks again burnout. I've not played with private tabs before but gave it a try just now and reckon it's certainly a good enough solution for me- and for work also I imagine, assuming we all have the discipline to only ever access the routers via private tabs. Might not be good enough for our Network God though (jeez they must've beat him long and hard in Siberia...) but I at least now have more ammo to fire his way. Reverting back to vanilla IE at work has been painful so I've a vested interest in talking him around.

I did try unchecking "Cache HTTPS After Sessions" previously and that didn't help in my case; I've been squinting at screens too long today to try your other suggestions just now but I will do later and let you know how they fare.