Login Script: Coding Forums Plugin - development needed and a view on its suitability

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Enjoy an ad free experience by logging in. Not a member yet? Register.

Whilst researching this I fell upon Mozilla Persona and it seemed the right way to go, separating the password from the user ID and providing a universal Mozilla managed ID verification account.

I noted that there is a general concensus of research opinion that currently 'web site security is in a very bad state', yet when searching for a login script, none of the big 3 systems appear in the search results (OAuth, Open ID, Persona).
It seems self-evident that if the secure systems are not promoted to the site developers (who are looking for such systems), then this bad state of affairs will continue.

I figured I could therefore kill two birds with one stone (three birds actually including website promotion), by instigating a project to develop the login script, learning & documenting how to promote the website, and therefore presenting it to everybody who is looking for such a solution (typically new developers such as myself).

I can make progress with SEO, and will document that, but I can't write the code to develop the script to its next stage.
Currently the script sets you up with a Persona account, and after user login, presents a verified email address (as the userID) to the developer.

As a short term fix, I've used local storage to hold the email, and deliver it to each page for the typical 'logged in as xxxxxxx@xxxx. com'.
Effectively a 'keep me logged in' system.

Clearly what is required is:
A mysql database solution, that can take the verified email address, check if it is in the dbase, if not then add it, if yes then populate any variables with that users website account data.

A system probably no different to the tens of thousands of site accounts, only far more secure, with no passwords being stored on the web, and with the dbase being setup using best security practice.

If this could be achieved, then it would be a huge advance for new developers, and for established developers, many of whom must be using insecure systems.

A worthy goal?

Rather than just talking about it, I set up a site making progress in understanding SEO techniques and what the SE's are looking for.
Much more to do, but at least okay to the point where I could put the project to Coding Forum Members.

So what does everybody think?

Developing scripts into a package and calling it a Coding Forums Plugin?
My thinking was that if the scripts were primarily developed by forum members, then it would be a de facto Coding Forums Plugin.

Ie. CF would get the credit, as would the individuals who put in the work on the scripts.
However, there is the question of 'branding'.... use of the CF name.
What do the owners of the site think?
Perhaps they'll look to the senior members views, or perhaps there is some legal aspects involved.

At the moment, the site is completely new.
Apart from the root, none of the pages are even SE indexed, so the only people looking at the site now are CF members.

I can easily remove references to CF, certainly in terms of any kind of official involvement.

I have been using my own home-grown version of the same thing for many years.

And ASP.NET provides something virtually identical as its means of user authentication.

Personally, I would trust my home-grown version more, simply because I wrote it and I *know* that it doesn't have some back door in it that is sending all my user's email addresses and passwords to some central site for collection and later use in Phishing or worse attacks.

I give up. What is so special about Persona???
And ASP.NET provides something virtually identical as its means of user authentication.
Personally, I would trust my home-grown version more, simply because I wrote it and I *know* that it doesn't have some back door in it that is sending all my user's email addresses and passwords to some central site for collection and later use in Phishing or worse attacks

I can't speak for ASP.NET as that is a Microsoft system, and I'm using Linux.
If it's secure then fine.

The question re Persona being special is most relevant to those entering website development, and those who are already established, but never mastered the aspects of secure login.

I'm sure that basket statement does not include many of the senior programmers on this site, but I'm confident the statement stands and is generally applicable.

Persona deals with many of the problems by removing the password, and encrypting it within ones browser ie. using two browsers, one registers twice.

The ID/email address verification is handled by Mozilla.

Clearly one then must put ones trust in Mozilla re the verification process (sending emails correctly), but they do not hold the passwords.

The passwords are held individually, meaning that there can be no mass break-in, grabbing passwords associated with account data.

Is this special vis a vis OAuth, or OpenID, or the Microsoft system?
I don't know...... but it certainly seems to make sense.

Further:
The developer now no longer needs to manage ID verification, nor store passwords.
This definitely makes life easier for the developer.

Is that a good thing?
Well.... if it works, and increases user security, then surely it must be good.

But it is a serious question.Is that a good thing?
Am I barking up the wrong tree here?

But assuming it is good..... the real advantage must then be for new site developers, who can quickly and easily gain a secure login system, in face of their other option, which is that they have little or no chance of gaining a secure system.

I mentioned on a previous post how, searching for 'secure login script', takes you into a morass of well meaning uploads, many of which being outdated etc.

Therefore it seems clear to me, that by providing well thought through 'mysql integration', the Persona login script becomes absolutely ideal as a website plugin.

But more.
There would be no need to stop there.

A 'single user session' script might compliment the plugin very nicely, allowing the session to prevent other people using the same ID at the same time.

Some developers might not want it, but others would..... I personally would.

However, overall, and in the spirit of your fair question... I would say that the Persona system may hold nothing of interest for yourself.

That's not the point.

It's for others.
More specifically, it's for those that need it.

Getting it to them...... now that's a different ballgame.
Starting from scratch.
Great project though.

Now why does it need to be taken beyond what Mozilla offers? Let me go back and re-read your first post.

Ahhh...you want to keep track to be sure an email address isn't reused.

But that is an ENORMOUS CONFLICT with this statement in your second post:

using two browsers, one registers twice.

How does that work, if an email address can't be used more than once? How many users keep around as many email addresses as computers where they might login?

I know that I login to CodingForums.com from several different computers during the course of a month. So I would need a different email address for each computer??? I happen to have the capability to do that, but I would sure hate it!

I'm trying hard to see the advantages of this system, but I'm not there yet.

And I see nothing that says it is bad to remember *HASHED* passwords on a server. (Presumably we are talking about a "one-way" hash, meaning that a password can never be recovered, only tested.)

And I see nothing that says it is bad to remember *HASHED* passwords on a server. (Presumably we are talking about a "one-way" hash, meaning that a password can never be recovered, only tested.)

Hopefully others here will chime in.

there's plenty wrong with storing MD5'd passwords on a cheap server. yes, it's one way, but that doesn't mean much if it's fast....

MD5 is super fast to generate, so once a hacker dumps and drops your mysql tables, he runs brute-force password generators, MD5's each result, and looks for matches on your DB's user table.

if fredbob1234 has an account and the password is brtueforced to "mayday1920", and they know from a previous corporate server compromise that chase has a user named "fredbob1234", and given that people are lazy, there's a decent chance that the chase account password will be a derivative of the "mayday1920" password on the just-hacked mom and pop site; perhaps "Mayday1920", "mayday1920chase" or "mayday1920!"...

openauth2 is pretty easy to integrate, and i trust its security mechanism of using location.hash to not leave behind any tokens on regular http pages or server logs.

Last edited by rnd me; 01-30-2013 at 12:17 PM.

Create, Share, and Debug HTML pages and snippets with a cool new web app I helped create: pagedemos.com

The passwords in the Persona system are strongly encrypted within each users browser.
When you login, the software checks the verified email address with the password in the browser, and proceeds to setup the session.

This means that any attack (to extract the password) would have to be focussed on an individual browser, hence the reason why, when using a mobile platform it is recommended to choose 'remember password for a single session' (which means re-entering the password each time a new browsing session is setup).

If it is your first time, you will nominate an email address, which will be sent an email, in which is the confirm link.

You will then have a Persona account setup in which you can add more email addresses if you wish.
I believe at the moment, when you close the persona account popup, you are already signed in (an improvement over the previous version whereby you had to then sign in yourself).

The script packs are in 'downloads'.
The original pack referring to BrowserID (the old name) and the authors original doc pack; and v1.01 where I have updated the branding, and moved the script code from the login page to a .js file.

The principal at the moment, is that the folder can simply be transferred to your root, and then linked to, allowing your own testing.

Ahhh...you want to keep track to be sure an email address isn't reused.

But that is an ENORMOUS CONFLICT with this statement in your second post:

How does that work, if an email address can't be used more than once? How many users keep around as many email addresses as computers where they might login?

I know that I login to CodingForums.com from several different computers during the course of a month. So I would need a different email address for each computer??? I happen to have the capability to do that, but I would sure hate it!

I'm trying hard to see the advantages of this system, but I'm not there yet.

Mozilla provide the service... it is the community that must produce the solutions.
The current script that I've chosen (because it was the only javascript option) provides the bare minimum of functionality - a starting position lets say.

If you have visited the site mentioned in the previous post, and tried it, you'll see that its output is an email variable, which is fine.

Signin Button
The signin button changes to your email address (after signing in)
If you click thru to main menu, and then return to 'Quick Intro & Signin', the signin button is back.

Not the end of the world - even on the Bing webtools site, after signing in, you are still asked to sign in...... it's just a bit slack.

However, with a developed solution, the signin button would disappear until you choose to log out.

Current Storage of the email/userID
I've just used local storage.
Any page then displaying ones userID simply pulls it out of storage.

On a subsequent visit, even if you don't sign in, your userID will display.
It's fine for starters, but the next step ought be to establish a website account specification, and then develop the scripts to achieve it.

Passwords/multiple PC's/Browsers
Each browser on each PC that is being used, will need to be registered once.
For simplicity, one would use the same password, and same email address for all browsers.

Once the Browsers are registered (using the std email system), then it becomes very easy for the user.

If your PC's are secure, you can choose to store the password for 3 months, in which case you will not have to enter a password again when logging in to a Persona enabled site (for 3 months).

Clearly the initial setup is a bit of a pain when you're using lots of browsers, but most web users will probably use a couple on the PC, and probably just one or two on their mobile platforms.

Either way, account registration is the price paid for password security.

The single User Session Concept
Would be a useful enable/disable feature for site developers.
For some sites you just wouldn't dream of enabling it, whereas for other sites, it would perfect.

For example: A site providing a paid for service, per member.
Say $10 per member per year.
A business buys membership and hands the password around to 20 staff, who would be getting the service for 50 cents.

Following on from my previous post vis a vis creating a website account specification:

This could be an ongoing process, adding features that would be provided in the plugin package.
However, the underlying principal would be to present a package that is as secure as possible.

OR if high security involves more cost

A layered approach, whereby a site containing no additional user information, could be setup for basic security, AND, where data should be securely stored - that should be catered for.

Really, the whole point of this project is to establish 'what is the current best practice for creating a mysql dbase browser session'.

Your statement above says it all, and begs the question:

Is it possible to setup a dbase that is not accessible to any two bit hacker?
What's the current status on dbase security on typical hosted site solutions?

I'm using the global service GoDaddy, primarily cos it was cheap, and the domain name acquisition was all linked in.

I chose the linux offering, and I believe they run all the latest software versions, and do offer TLS/SSL at additional cost.

Was this one of those 'cheap' servers that you had in mind?

The point is that millions of developers use services of this nature, therefore we really need to understand what the security implications are, and whether or not it is even possible to create a secure website account.

Is it possible to setup a dbase that is not accessible to any two bit hacker?
What's the current status on dbase security on typical hosted site solutions?

I'm using the global service GoDaddy, primarily cos it was cheap, and the domain name acquisition was all linked in.

I chose the linux offering, and I believe they run all the latest software versions, and do offer TLS/SSL at additional cost.

Was this one of those 'cheap' servers that you had in mind?

godaddy is the prime example of what i was talking about, they have been breached several times; i know from personal experience.

the dbase itself is not the issue, mysql patches up any problems before they get out of hand. It's the php that gives away the keys to the kingdom. I can't tell you how many PHP snippets i've seen posted in forums that simply concat $GET_['someParam'] into the SQL statement. a chain is only as strong as its weakest link.

you can ramp up security on any plan or server. If on a server you don't trust, host the DB on another, non-public site and use POST to talk from your public server to the safe server's DB. that gives you an extra layer of protection because if your public site is compromised, all it can do is request the pre-set actions you defined in the private server's http interface, which hopefully won't include "drop table users"...

i think that getting the password and user list off of the site is good all around. It reduces the site's legal liability significantly in most jurisdictional situations. It puts security in the hands of security experts instead of busy site developers. Finally, it's just easier for the user to click a few oauth2 (or whatever) buttons, with remembered values, than to have to type in names, passwords, or email accounts.

easier UX equals better security and fewer post-it-notes on the sides of monitors.

Last edited by rnd me; 01-30-2013 at 10:59 PM.

Create, Share, and Debug HTML pages and snippets with a cool new web app I helped create: pagedemos.com

Users who have thanked rnd me for this post:

i think that getting the password and user list off of the site is good all around. It reduces the site's legal liability significantly in most jurisdictional situations. It puts security in the hands of security experts instead of busy site developers. Finally, it's just easier for the user to click a few oauth2 (or whatever) buttons, with remembered values, than to have to type in names, passwords, or email accounts.

easier UX equals better security and fewer post-it-notes on the sides of monitors.

This is exactly how I've been thinking.
Yes the 'ease of use' is a great bonus, but primarily the key is that it allows a developer to learn to drive a car, without him having first to learn how to manufacture a braking system.

Yet in our case.... that IS the discussion.

Obviously it is a massive subject, but perhaps by pigeon-holing the areas, it might be possible to understand the basic risks, and hone in on the areas that can be controlled.
(my list may be incomplete or incorrect)

1. Physical servers
I've no idea here whether having the latest hardware is key..... Is hardware just added to, as demand increases, meaning there is a generational mix of hardware.
Or should we choose a hosting provider by the kit they have?

2. Server maintenance staff
There is nothing we can do about this, but presumably they can get in our accounts.... or can they?

3. O/S
I don't know whether one O/S is better than another vis a vis security, but perhaps there is a consensus league table?

4. How the O/S is coded to create the domain
I'm just wondering whether this is the area linked to the statement made by Rnd me re: http interface.

He implied, that by minimising the number of actions a server can run (in response to external commands), the DB contents are effectively secure.

If this is the case, then a fundamental level of security can be implemented quite high in the hierarchy, if you can ask your host to re-configer the http interface for your domain.
OR is that impossible in terms of the restricted instruction set being only applicable to a DB rather than a full domain?

5. Provided Software
I would guess holes are patched as they are discovered, but in the PC world some software is considered more vulnerable than others.

6. How the developer codes instructions
Surely here, if we were to author a plugin whereby a mysql example account is pre-setup, using best practice coding to pull data from the DB into the website (and vice versa)...... the noob developer would merely need to repeat those best practice instructions in order to grow their site.

At any rate; that was always my thinking vis a vis creating a complete plugin..... building upon the front door lock that Persona provides, rather than having a secure front door, but leaving all the windows wide open.

7. The no choice - 'this is how you code it' elements
Is it not the case that you must communicate with the DB using a password, which means there is always a risk of hacking, or is this area fine?

8. Encryption of transmitted data SSL/TLS
Is this used purely to protect data in transit, or does it also play a role in protecting the DB?

9. Dual servers 'public and private'
One's domain would be hosted, but the DB would be on a server at a more specialised self-manage server enterprise?
Or is it just a case of separating the DB from the domain so you can limit the instruction set?
(I guess any response to point 4. will answer that question.)

10. Other measures to increase security
What are they, and would this simply be a case of following best practice?

Filling in the responses to the above questions, would produce a very useful document (IMO), forming the basis for a background document that would associate well with a scripted plugin.

But primarily, for me, it helps the brain think & learn because the chaos suddenly gains order, and it becomes clear where you need to look and what questions one might ask.

I've been having a good root around for info on this topic.
What's surprising is that there doesn't seem to be a collation of advice, so it's quite hard work, particularly when considering the date of the info.

2. Server maintenance staff
Surprisingly not a great deal of discussion; perhaps because there's nowt you can do about it.... but views were expressed that they could get at your data.

I used to be a trouble shooter in the uk, and got a contract to fix a treasury vault door system..... the door was amazing - massive in the true sense.
The sys was crap - I asked for the code to (maintain the charade), but when they didn't give it to me (what?) I simply bypassed the code to open & close the door.

I just hope its a little bit harder for server admin chaps.

3. The O/S
Berkley Software Distribution is considered the most secure server os.
They claim Only two remote holes in the default install (in 15 years to date).
I see rackspace provide BSD hosting

4. How the O/S is coded to create the domain
I'm not sure about this re: rnd me's statement 'pre-set actions you defined in the private server's http interface'.
Is this accomplished using htaccess file?
If so this is available in Godaddy so presumably its the norm.

5. Provided Software
The advice here is pretty obvious - that latest versions are key.
Set PHP register_globals OFF: PHP6, there will not even be a Register Globals setting

6. How the developer codes instructions
Lots of info on this, but it comes down to using best practice

7. The no choice - 'this is how you code it' elements
Same here - it does seem that PHP contains a good deal of risk.
Escape the input using the function mysql_real_escape_string before sending the SQL query - was mentioned. Presumably it is just lazy programming if you don't.

(points 6 & 7 are the same thing)

8. Encryption of transmitted data
Recommended is both SSL encryption between DB & client and similar encryption when saving to the DB. I noted with interest that:
'having only a certain page that contains sensitive information (such as a log-in page) of a website loaded over HTTPS, while having the rest of the website loaded over plain HTTP will expose the user to attacks'.
Presumably the drawback could be painfully slow page delivery.

9. Dual servers 'public and private'
This was interesting - I was searching for something like secure server hosting and this came up: www. 1freehosting. com/
A totally free server, whose blurb talks more about security than any of the server hosts I've looked at - see their FAQ & Features.

Perhaps a server where the DB could be hosted, and it's free... for ever...
There has to be a catch.
But even if it is speed - the DB comms would typically be just a few bytes.

What do you think?

10. Other measures to increase security
Nothing further here.

Overall: a few snippets of useful info, but probably an improved focus on what areas to delve deeper into, whilst eliminating others.

After that last post looking at general security settings..... it seems like its so easy to think that because the initial script was javascript, one posts in javascript.

However, much of this project revolves around mysql, php, javascript, and apache settings (I believe so).

Where then to position the project?

The general web building arm clearly seems to be more of a visitor resource.
My initial post on this topic has over 8000 hits and the only responses were from when it was posted on javascript forum.

If this 'secure login project' has legs, and hopefully it has (it's worthy surely).... where then is the best branch of CF to carry the core project forward (with perhaps ventures into the relevant forums when applicable)?

What is the project?

To integrate the secure verification/login that Persona provides, with a real world website requirement for website member accounts, and the data that is then associated with each account, all achieved using best practice coding, and, as we have learned, providing advice on the levels of security (setup) that should be incorporated, according to data sensitivity.

i would guess that codingforums itself is not the ideal endpoint for the project, though it can be a big part of it's building and prorogation. The thing is, newness and security don't jive in the mind of IT folks and devs in general. The devil you know is less scary than the one you don't. That not to say either devil is more or less harmful, just that one is comfortable to folks who build sites.

the collection of information displayed here is impressive. I think that with some editing, it could become a great checklist, or even more: a test. Using a series of true/false questions about a web setup, one could objectively asses the risk profile. for each good step, you get a certain number of points: +3 for https, +2 for bsd, +5 for mySql_esc_str(), +5 for not using php, +2 for disabling globals, +10 for using node.js, etc. 60% is passing, the most secure sites can eek out <99%.

the other train of thought i had while reviewing this was that perhaps you can code a secure user setup, and then sell the service as a JS plugin to any site. You could sign-in users, and keep a small amount of user config, and charge a small amount of money for the service. You would have to do your homework and keep your setup top-notch, but that would allow others to stand on your shoulders. If it were as easy to integrate as facebook, i think you have a helpful and profitable software solution to a common problem.

keep us informed!

Create, Share, and Debug HTML pages and snippets with a cool new web app I helped create: pagedemos.com

Users who have thanked rnd me for this post:

The thing is, newness and security don't jive in the mind of IT folks and devs in general. The devil you know is less scary than the one you don't. That not to say either devil is more or less harmful, just that one is comfortable to folks who build sites.

Yes sure.
But scratch 'IT folks and devs in general', and replace it with 'humans'.
However a truism doesn't mean to say its not bollocks.

I woke up today to learn that Twitter had been raided, with a loss of 250,000 passwords and associated account data.

A spokesman apparently considers that a quarter of a million peoples data is a minor event......

While another piped up "It was the Java that did for us".

Yes, well maybe it was.
Who knows what commercial enterprises will say when in crisis mode.

The fact is: that with the ever growing integration of the net into our lives, the mass storing of our passwords is becoming more and more untenable.
All the more so now, with powerful nations bringing to bear, near unlimited resources both technical & manpower, to the task of cracking open our often flimsy vaults.

It seems clear to me, that the time for a Persona solution has arrived.
Right now, is the right time.

You know what they are saying now (who are they?)
We should all practice "good password hygiene".

What is that?
A different password for every account, each more than ten characters long mixing numbers and case (oh yes..... and then regularly changed).

ROFL.

What are these bods smoking?
You just hope that some of these guys get raided, to show their daughters name as their password, and their first school as the stupid password question.

Oh I forgot..... That Alaskan lass got done for that already (chortle).

What does it take to change peoples attitudes?

When the first m/c gun was demonstrated to the British Army (by chopping down trees with it) the top General present proclaimed 'yes but trees don't fire back' (and thereafter we had the flower of our youth marched to their slaughter).

We see the signs, its just a question of making the change.
And is it such a big change?

All the DB risks are still there.
This system simply solves the password problem, and offers the prospect of a simple to install secure login package for noobs and pros alike - perfect - and we can do that.

Originally Posted by rnd me

newness and security don't jive in the mind of IT folks and devs in general.

In my opinion and experience, it is ONLY newness in security that will keep us one step ahead the gangs of criminals, that are, sadly, out to get us.

Sorry if this comes across as a bit of a rant.
It's not... it was thought through.

Re: the idea of a graded checklist - I thought was good, and the jsquery plugin very interesting.