My internet anti-virus has suddenly started warning that the C4P website is insecure, as of yesterday.
Usually when this happens it seems to be because a site operator has omitted to renew a certificate.
Is this a concern?
|
>> Usually when this happens it seems to be because a site operator has omitted to
>> renew a certificate.
That's one possibility. Another is that site is using http rather than it's secure derivative https. As we're transmitting non-sensitive information intended for viewing in a public site then I don't think it's a problem vis a vis content.
Might issue for some users though if hacking passwords is possible and they use same password elsewhere.
Last edited by: Bromptonaut on Mon 13 Aug 18 at 09:26
|
I was wondering why it had suddenly happened. Nothing has changed at my end - same AV software, same settings, but now it warns every time that the site is insecure.
This has happened only once before, with another website a few weeks ago, and when I questioned it the administrator admitted they had not renewed the certificate.
Could you amplify on your "No" response Zero? It's a little short on explanation, and you do appear to be an expert in this field?
|
Some advice would be appreciated on what to do please.
Is it safe to change the AV settings so that it thinks C4P is secure?
At the moment I permit it each time, which is a pain.
Thanks
|
1/ None of my multiple PCs with multiple OS's and Browsers has reported an issue.
2/ No-one else has reported an issue
3/ Assuming you use a unique user id and password for this site only, and because you dont pass any or store any other information on this site, security is not an issue.
Given the above, set your AV to allow the site.
|
I suspect that all is OK, and you have already been given advice to this effect above.
...are you using Chrome as a browser?
Chrome auto-updates itself in the background, and a (very) recent such update has introduced the treatment of all sites that don't utilise secure data transfer via the HTTPS protocol as "insecure". It flags these as so on the "address" line.
All this means is that data that is transmitted between yourself and the particular website is not automatically encrypted in transit, and so could be intercepted and read. For many/most websites one uses this is of little concern, as interception of such data is not likely to be compromising (about the only issue I can think of is if you use the same password on multiple sites, some of them "critical", then it could give the opportunity to trawl a potential userid and password list to try on those, other, critical sites).
There is a general drive across the web to implement secure transfer, even where it isn't really critical, and browser providers are tending to move to flag those sites that don't/haven't yet implemented it. Whilst I've used Chrome as an example as it roughly fits the timescale of your change, I suspect other browsers and or AV suppliers are making/have made the same change.
So, if it is that, nothing at all has changed from your historical use, it is simply that the browser is now reporting the nature of the connection differently, and flagging where "HTTPS" has not (yet) been implemented by the website.
On my version of Chrome (which changed in the last week or so to version 68 implementing the changed practice) "Not secure" is flagged against URLs in the address line reported as "www.xxxxx" whereas "Secure" is flagged against those reported as "https//www.xxxx".
Last edited by: tyrednemotional on Tue 14 Aug 18 at 09:22
|
It is indeed because this site is not implementing HTTPS. Probably wont either because no secure information is passed to or from it.
as long as you use a unique password for this site
(a good idea anyway, I seem to recall passwords on this site are not hashed)
Last edited by: Zero on Tue 14 Aug 18 at 11:47
|
Thanks.
I'll just add it as an exception then.
(Firefox browser, Malwarebytes AV )
Last edited by: Cliff Pope on Tue 14 Aug 18 at 15:29
|
>> (a good idea anyway, I seem to recall passwords on this site are not hashed)
On an earlier version of Khoosys forum software, passwords were not hashed. They are now and have been since before Car4Play was setup. It was the HJ website that was compromised.
|
|
The passwords some people chose was mindboggling.
|
|
'Mindbogling" was one of my passwords in the early days.
|
I have no idea what mine would have been, though I could probably narrow it down to two or three.
One of the problems of always having unique, obsure and unpredictable passwords and never reusing any of them is that one needs a reliable yet unconventional way of choosing them.
Last edited by: No FM2R on Tue 14 Aug 18 at 20:38
|
>> I have no idea what mine would have been, though I could probably narrow it
>> down to two or three.
>>
>> One of the problems of always having unique, obsure and unpredictable passwords and never reusing
>> any of them is that one needs a reliable yet unconventional way of choosing remembering them.
there, fixed that for you
|
|
Well, it's a small point, but I have no reliable way of remembering them beyond knowing the method by which I chose them.
|
>> I have no idea what mine would have been,
IIRC, it was **********
|
>> The passwords some people chose was mindboggling.
>>
Clever, in view of Z's reply... :-)
|
Yes it’s the lack of https that some browsers whinge about especially when entering a password field.
When I get some time I’ll add a certificate...
|
Website insecure? - Zero
