Fretboard site not secure

Fretwired

I've started to get 'site not secure' warnings which I think is simply because the site does not have a secure https URL.

https://thenextweb.com/google/2015/12/17/unsecured-websites-are-about-to-get-hammered-in-googles-search-ranking/

webrthomson

Fretwired said:

I've started to get 'site not secure' warnings which I think is simply because the site does not have a secure https URL.

https://thenextweb.com/google/2015/12/17/unsecured-websites-are-about-to-get-hammered-in-googles-search-ranking/

There is no SSL attached to the site - why would it need one really other than login there is little that is sensitive being passed about.

That seems an odd decision by Google many sites will have areas that have no requirement for https to delist them as they are not secure is somewhat perverse.

Fretwired

webrthomson said:

Fretwired said:

I've started to get 'site not secure' warnings which I think is simply because the site does not have a secure https URL.

https://thenextweb.com/google/2015/12/17/unsecured-websites-are-about-to-get-hammered-in-googles-search-ranking/

There is no SSL attached to the site - why would it need one really other than login there is little that is sensitive being passed about.

That seems an odd decision by Google many sites will have areas that have no requirement for https to delist them as they are not secure is somewhat perverse.

Google announced this years ago and are now ratcheting it up. Most hosting packages come with https as standard ..

webrthomson

Fretwired said:

webrthomson said:

Fretwired said:

I've started to get 'site not secure' warnings which I think is simply because the site does not have a secure https URL.

https://thenextweb.com/google/2015/12/17/unsecured-websites-are-about-to-get-hammered-in-googles-search-ranking/

There is no SSL attached to the site - why would it need one really other than login there is little that is sensitive being passed about.

That seems an odd decision by Google many sites will have areas that have no requirement for https to delist them as they are not secure is somewhat perverse.

Google announced this years ago and are now ratcheting it up. Most hosting packages come with https as standard ..

Still seems a dumb decision both http and https have their place on the web to universally decree one is bad and the other is good is both simplistic and wrong.

On a guitar forum where we have no financial data being transmitted and (I'm assuming) the password are already sent encrypted what is the actual point of encrypting the session between you and the webserver. The only thing adding SSL is doing here is adding overhead - payload encryption/decryption, cost of SSL cert, adding the SSL to the hosting costs, remembering to renew the damn certificate, the inevitable scenario where you get incorrectly added to a certificate revocation list etc.

Now were this a banking site or stock trading platform it would be different, SSL would be a must as the transmission is sensitive (and probably required for PCI DSS anyway).

guitarfishbay

People do sometimes give bank details via PM for payments 

bloodandtears

This site can also store details about an individual, which is also something being brought under scrutiny

webrthomson

guitarfishbay said:

People do sometimes give bank details via PM for payments 

That is a good point and it would make that PM about as private as a post card and hence a bad idea. Fundamentally that is a misuse of the system much like doing it via email would be, we are not however thinking about encrypting our email because people misuse it

Okay we might be encrypting our email if Google have anything to say in it!

aord43

I am on the fence about this but there is much discussion around the web about it.
https://lemongrassmedia.co.uk/https-better-website/
By the way I am viewing in Chrome and it doesn't warn me of anything unless I click the info button, and then it says I shouldn't send sensitive information.

Secondly @webrthomson said "and (I'm assuming) the password are already sent encrypted" - is that really the case if https is not being used?

TTony

webrthomson said:

guitarfishbay said:

People do sometimes give bank details via PM for payments 

That is a good point and it would make that PM about as private as a post card and hence a bad idea. 

The only details that you need to give for a bank t/f payment are the same details that are pre-printed on every cheque that was ever written ...

@digitalscream will give the full answer on why we're not secure - because he's done it before.

webrthomson

aord43 said:

Secondly @webrthomson said "and (I'm assuming) the password are already sent encrypted" - is that really the case if https is not being used?

Yes. Normally the password is encrypted before being sent irrespective of whether the session is https or not and then decrypted at the webserver to allow you to login.

The password encryption is totally separate from the http/https thing which is, when https is on, encrypting the entire session between the browser and webserver.

That said I'm assuming things here - and we could be sending password in clear text over http - which would be bad

I'm sure we are not.

paul_c2

I think the reason Firefox etc now give a warning that the site is insecure is precisely because things like passwords, which people assume will be kept safe, ARE sent as cleartext over the http connection, thus can easily be found out if a "man in the middle" style hack occurred. And while you might not put or send sensitive information eg on this forum, the password may be the same one used on other sites where sensitive/personal information IS transmitted, thus opening yourself up for financial loss by that route.

Personally I have tons of logins, but only a handful are actually financially sensitive ones (eg paypal, my bank, etc) and for those I use a different password than forum accounts  etc.

webrthomson

paul_c2 said:

I think the reason Firefox etc now give a warning that the site is insecure is precisely because things like passwords, which people assume will be kept safe, ARE sent as cleartext over the http connection, thus can easily be found out if a "man in the middle" style hack occurred. And while you might not put or send sensitive information eg on this forum, the password may be the same one used on other sites where sensitive/personal information IS transmitted, thus opening yourself up for financial loss by that route.

Personally I have tons of logins, but only a handful are actually financially sensitive ones (eg paypal, my bank, etc) and for those I use a different password than forum accounts  etc.

That is a fair point you are trusting sites to have done things correctly and I'm sure some don't!

As you said better safe than sorry have separate passwords for sensitive stuff.

aord43

webrthomson said:

aord43 said:

Secondly @webrthomson said "and (I'm assuming) the password are already sent encrypted" - is that really the case if https is not being used?

Yes. Normally the password is encrypted before being sent irrespective of whether the session is https or not and then decrypted at the webserver to allow you to login.

The password encryption is totally separate from the http/https thing which is, when https is on, encrypting the entire session between the browser and webserver.

That said I'm assuming things here - and we could be sending password in clear text over http - which would be bad

I'm sure we are not.

Actually it's almost as bad.  If someone can intercept your connection and get your username and encrypted (actually it would be hashed) password over a plain HTTP link, what's stopping them using them to log in as you?
Anyway I don't believe this is done.  I think passwords are sent in plaintext.  Willing to be educated if you know the details though.

vasselmeyer

Just because the site doesn't use  https (http over SSL ) for its traffic does not mean the authentication you use for this site is also sent over the same transport. In fact, knowing what he does for a living and having chartted with him at the guitar show about non-guitar stuff, I would be amazed if @digitalscream hasn't implemented process using a hashed and salted database for password comparison. Additionally, you can also use Google and Facebook authentication if you choose and you can be 100% sure that those credentials are secured.

digitalscream

Okayyyyyy....I'm here. Had to all kick off while I was doing my carpenter thing, didn't it?

Right...here's the lowdown on where we are:

- We're not HTTPS protected. Stating the obvious, but got to start somewhere.
- Yes, unfortunately your passwords are sent in plain text from your browser to our server at the moment.
- Authenticating with Facebook or Google bypasses that to a certain degree (although it's not perfect).
- At no point - other than initial login - is your password stored in plain text. They're all hashed in the database, and they're omitted from all web server logs.
- Bank details are relatively safe anyway - after all, we wouldn't be giving them out to people we've never met if they weren't.
- PMs are stored as plain text in the database, but the server is as secure as it can be (it's locked down such that the database server isn't actually accessible except from the server's local network, so the only way to get access is to compromise the server itself...and if that happens on any site you pass details on, it's game over anyway).
- I'm the only one with access to the server; yes, that means I could read your PMs, but I don't because I actually have ethics (surprising, I know....) and I'm not that interested in what people are saying anyway....

So...the future...

HTTPS is something I'm currently working on. Unfortunately, implementing it right now would fuck up half of the site because most of the client-side Javascripts in use by the plugins are, for want of a better expression, shit. It's mainly down to the forum plugins, but they provide essential functionality that we can't live without - the editor, for example.

I'm getting through them slowly, but it means testing every script one-by-one and I only have so much time in the day. This isn't something I can farm out, because they're all so inter-related it's a case of load forum -> test function 1 -> find broken script -> fix script / find version that works -> test function 1 -> load forum -> test function 2 -> find broken script -> fix/find version that works -> test function 1 -> fix incompatibilities with new function 2 script -> etc etc. I have to work within the confines of the software we have, and it's not the most developer-friendly of codebases (and the community developing plugins are typical PHP developers, so nothing's written the way you'd expect it to be).

Of course, this new development with Google has lit a fire under me, so I'm clearly going to have to find a way to accelerate the process. I'm hoping I'll be able to get something working within the next four weeks or so...basically, bear with me

notanon

I've been using the free letsencryt certificates. Fairly simple to setup the 30 day renewal system.