Re: 38k Member Forum
Reply #15 –
Or activate the session and require a password confirmation (just to make it clear).
When inflicting change on a hundred thousand people, it is wise to make it go as smoothly as possible >_>
Re: 38k Member Forum
Reply #16 –
Just my 0.02, but I think that stressing it so much about re-typing a password is... Really, really overkill.
Re: 38k Member Forum
Reply #18 –
I understand why they'll have to type the password in a second time, it's mostly just a wording change.
Re: 38k Member Forum
Reply #20 –
The old one has issues but I'm not sure if the new one is any better, I haven't looked at it.
Re: 38k Member Forum
Reply #21 –
The main issue with the old password hash was, basically if a forum database was compromised, the saved hash could be used to login to the system ... you did not even need to know what the original password was,
If a someone used the same password on other sites (with the same forum software), they could use the hash to login there as well. So your site may be secure, but you were still vulnerable to all other similar sites, and although the original user password was "safe" it did not matter anyway.
With some edits I believe you can have the old work on the new, have not really thought about that, but you did give up some level of security as discussed.
Re: 38k Member Forum
Reply #22 –
I know how it works in SMF.
What I was doing for my own custom CMS was to have both the client and server perform some of the hashing work - with the client doing most of it. The client would do sha512 256 times, and send the 255th and 256th hash to the server in base64 (88 characters).
The server would verify the client had hashed correctly, then hash the 256th hash a few more times (along with a salt) before storing/checking the database.
This IMO gives the best of all possible worlds
- It can allow any size of password, it only ever arrives at the server as 88 characters
- This is one of those rare situations where we can verify client-side crypto.
- No more username salt nonsense
- Offloads some cpu cycles to the client.
- Still not sent over the wire in plaintext.
- Still hashed on the server, so getting the database doesn't get you any closer.
Is what I would like to see, personally.
Re: 38k Member Forum
Reply #23 –
Keep in mind that it should always work with JS disabled or absent.
Re: 38k Member Forum
Reply #24 –
What follows is a comprehensive list of the sorts of people who visit my site without functional javascript:
1) Spammers
2) Scrapers
3) People who have it disabled via noscript and can trivially enable it for my domain
4) More scrapers
5) More spammers
So no. It is perfectly valid to require functional javascript from people who wish to log in.
Re: 38k Member Forum
Reply #25 –
/insert snarky reply about a comprehensive list of uses for Javascript
I wonder if you actually checked your statistics before making that statement. You just might be surprised. I looked at my statistics, and their sheer variety managed to do just that. On my forum the most popular browsers in March were (in order) Firefox, various Chrome derivatives, Otter, Opera/Presto, K-Meleon, w3m and ELinks. That's trailed by e.g. Internet Explorer (at a still respectable ~9%), while Edge doesn't even make the top 10. Linux use (not including Android) is 16.1% and BSD is at 1.2%. And keep in mind that bots use a user agent that says Windows with either Firefox or Chrome, so in real terms much of that is likely significantly higher.
Yes, my forum is atypical. But most of us care deeply about this kind of thing. It's why I selected SMF and I've had plenty of positive feedback about how well it works with Javascript disabled and how well it works in older, alternative, and text browsers. Sure, we could trivially open another browser instead of Links2 or Netsurf. Yes, we could trivially enable Javascript. So what? We can also trivially close a site that's broken by design. Would your solution even work with screen readers? In short, know your audience. ElkArte's audience is obviously a lot wider than my audience, but it isn't synonymous with your audience either.
PS Regarding using Javascript to keep out bots, for that purpose it wouldn't make much sense to require it on every login. Requiring JS on the registration page would have the same effect — or lack thereof, depending on the sophistication of the bot. And come to think of it, I think my users may well be a lot more sympathetic to "please enable Javascript to register (this helps keep out bots)" than to "please enable Javascript to login."
Re: 38k Member Forum
Reply #26 –
Most of user-facing parts of Elk work without javascript. IIRC, the only "big" feature that require JS by design is the likes, anything else should pretty much work.
I the admin panel there are some pages that may have problems if JS is disabled, since the general consensus has been is acceptable to require JS in the admin panel (and some moderation functions).
Re: 38k Member Forum
Reply #27 –
You could, you know, just ask. I have dozens of blind members using a variety of screen readers. Yes, they parse javascript, have for decades. Can even read the ajax chat. They will be actively testing the Elkarte 1.1 betas for us. One uses JAWS even. : )
JAWS is important because it tries to outsmart the web designer. >_>
And if you want to see what useragents are bots, swapout your login url. Enjoy. Have not done this in years, but long story short I dropped IE6 support for Elliquiy when I realized every single IE6 user attempting to sign into my forums for the past year was a bot. 98% of the remaining bots were IE7-9. A handful of Firefox 3 & 3.5.
True, 'know your audience' is a thing. I had one lynx user for awhile - he was very vocal about it. I actually had a very simular argument with him.
Fact is, if you want to actually make an account and log in, I don't feel it is too much to ask for you to spare a few cycles to help secure your own password. If you are competent enough to know how to selectively disable/enable javascript, that should not be that much of a leap to understand why.
Ultimately, my forums are writing forums. My members have a reasonable level of sophistication - many use Linux, even - but they don't subject themselves to browsing from the console for the most part. They are there to read and write with each other.
And yeah, SMF working without javascript was a part of what drew me back in 2005. Now? Now I want the interface out of everyone's way. SMF/Elkarte is due for a colossal refactoring, from multiple angles.
Re: 38k Member Forum
Reply #29 –
Well, it stops heartbleed-like sniffing, for example, as well as firesheep.
More pertinent is that by having the client do most of the hashing, you reduce some of the attack footprints against you (you still need to hash, of course, but still). No million-character passwords (an attack against Django for a time), no repeated login attempts eating up cpu cycles, etc.
In my Phoenix implementation it loads the login form in Javscript, yes, displaying a notice if not ('You need javascript in order to sign in or register') - the idea there being that a user should not have to even reload the page to login.