Skip to main content
Topic: 38k Member Forum (Read 11400 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

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.
~ SimplePortal Support Team ~

Re: 38k Member Forum

Reply #17

@Vekseid what do you mean with "activate the session"?
If it is what I think it could be you'd have to basically maintain the two systems in parallel and use the one used by the member.
I think that, if you really want to avoid any hassle, it would be easier to just drop the migration of the passwords to the new encryption and continue to use the old one.
It's probably the only way that will ensure nobody is going to have to type the password again.
You have to decide which is the trade-off: if you are sure members will not know their password and will have a broken email, then rely on the volatility of a cookie is your only option to make all of them happy. :)
Bugs creator.
Features destroyer.
Template killer.

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 #19

Quote from: emanuele – I think that, if you really want to avoid any hassle, it would be easier to just drop the migration of the passwords to the new encryption and continue to use the old one.
It's probably the only way that will ensure nobody is going to have to type the password again.
You have to decide which is the trade-off: if you are sure members will not know their password and will have a broken email, then rely on the volatility of a cookie is your only option to make all of them happy. :)

So, there is an (easy) way to keep the old passwords and the old encryption? There is an option somewhere in the migration process?
If I choose to do this, can I (easily) change to the new encryption at a later time?

I am thinking if there is really a big and serious reason to change to the new encryption. How unsafe is the old one? I mean, it΄s not like passwords in plain text. And we have been using this system for almost 15 years... (since the YaBBSE days...)

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.[1] 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,[2] 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.[3] 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."
Not even necessarily on Javascript use, although I bet you do not in fact have any statistics on that, ;) but particularly on how long it took before people enabled Javascript. And I'm not just saying this to be argumentative; I'd be curious to know.
Many of which on Android. Incidentally, this includes the majority of spammers. Let's ban user agents that say Chrome to prevent spam, shall we?  O:-)
That's me speaking. I don't use w3m and ELinks… yet. I have to admit I've become quite curious about their popularity now.

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[1], 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).
that anyway does work without JS, just the interface is not exposed i.e. the button doesn't have the appropriate URL, but if you really want that, it should be rather easy to fix.
Bugs creator.
Features destroyer.
Template killer.

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 #28

Quote from: Vekseid – 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. : )
Cool.

Quote from: Vekseid – 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.
NB I never said I was opposed to adding extra security, merely that I was opposed to purposefully breaking things with JS disabled. Obviously, from a security standpoint the addition of Javascript does eliminate most potential sniffing dangers. From the top of my head, the only attack I can think of is that someone in the position to sniff may also be in the position to alter or block the JS sent to the user so that they get a nice unhashed password, but that would take more effort. Encryption would guard against the latter possibility, but in that scenario you probably wouldn't gain much from hashed passwords in the first place. (Correct me if I'm wrong.[1])

What I meant to imply when I called for us to "keep in mind that it should always work with JS disabled or absent" is a warning message, for example:

Code: [Select]
<strong class="noJS">Warning: with Javascript disabled your password may be at greater risk of being sniffed by some script kiddie and/or the NSA.</strong>

coupled with, e.g.

Code: [Select]
$('.noJS').css('display', 'none'); // or however one might accomplish that in jQuery

And of course in my proposal you'd also flip the switch on a hidden INPUT element indicating whether or not the password comes prehashed.

Note that a warning or error message along those lines is a necessity regardless whether or not JS-less logins are supported. Javascript may have failed to load even when enabled because it was filtered by a proxy/firewall/malicious entity. As such, in a JS-only scenario there should be no forms on the page to prevent any accidental submissions. To prevent the layout from breaking you could just clone the children of a relevant DIV inside a newly created FORM element.
Edit: It occurs to me that it'd potentially mitigate some risk in case of a compromised server, although again there you have the issue that the attacker could simply alter the JS.
Last Edit: April 04, 2016, 10:16:34 am by Frenzie

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.