50c buys you someone else's password for Netflix, Spotify or ... Criminals are selling 'lifetime' Netflix, HBO, and cable sports streaming accounts for less than US$10 on sites hidden within Tor. Premium sports accounts sell for about $10 while streaming TV can be bought for as low as 50 cents, far less than the $10 monthly subscription. Comic fans can buy a stolen Marvel Unlimited …
Guesses like 'username' / 'password' are likely to get you in faster that filling out the enormous form. The form certaily wastes more than 50¢ of time. The only downside is the amount of time required to make a darknet purchase compared to the fun finding the stupidest combination of selections if someone has not setup 'username' / 'password' already.
I remember charging 50p at school for forging parents signatures on detention slips. I had a knack for it copying from homework diaries. Was a good little earner till someone squealed to it :( had to move to selling cigarettes then and that was a crowded market.
I sold homework. Worked well until one of my regulars decided that stealing it from my locker was better than paying me a few bucks. He got caught and turned rat. Fortunately, some of my other regulars took care of things and I was able to get back to business pretty quickly with no more hiccups.
Fucking lucky our commentard accounts on el reg are secure then. Nothin' worse than sending passwords in plaintext.
An SSL cert is $10, you cunts. I'll help you install the fucking thing if it's a problem. $10 won't buy you an A+ here:
https://www.ssllabs.com/ssltest/
...but vaguely showing interest is better than not bothering. The NSA and GCHQ and all the other fuckers have our passwords already; I know. But as a tech site specialising in moaning about surveillance, you should do SSL just to piss them off, if nothing else.
Way I see it, people commenting on El Reg should be tech savvy enough not to be reusing log-in details from other sites, and realise that anything posted is public anyway. i.e. it would be better if an SSL certificate was in use, but it's no big deal.
(Commentards hiding behind less open user ids than mine may have different feelings about it!)
If you have a decent password manager you should also be able to change passwords more frequently. We tend to find out the true extent of a breach weeks or even months afterwards. By changing passwords to more important sites on a regular basis (like your banks and credit cards) you stand a better chance of locking out nefarious folk sooner when a breach occurs.
Eeh... There are steps to be taken to ensure we can use TLS across the sites, and unfortunately things are a tiny wee bit more complex than installing a cert and calling it a day. If you seriously believe that's all it takes, don't take it wrong if I don't take you up on the offer to help out, but instead ask you to get as far away as you possibly can from being able to "help" ;)
For context,
Installing a cert and making the site available over TLS sounds like 99% of the work, but in reality it's - for me - a _literal_ press of a button. It's piss easy; it's straightforward: we already use TLS for private stuff which _requires_ us to have secure authentication. We strive to get an A on ssllabs, but that might mean that older browsers/OSes would be unable to connect, and we can't (yet) have that for our main site, can we?
It's easy to notice that (most of) the images on the site are served (thanks to cloudflare) over TLS - mainly to ensure that recent browsers can download them in parallel, and partly to assess the impact of enabling TLS for at least part of the audience.
The difficult/lengthy part in all of this endeavour (enabling TLS on the main sites) is ensuring the rest of our infrastructure can properly work under TLS, that users can use TLS across the sites (account, forums, whitepapers, …) and that the business doesn't collapse overnight due to people switching to TLS only (think, ads), etc. etc. This is the actual 99% of the work, which we've been making strides towards for a while. It'll all eventually converge, and we'll go live with "it" when it's possible, when it makes sense to, and crucially when we've tested the shit out of it.
So, Soon®
OK, you make some good points. And I may or may not have been spectacularly trashed when I stomped my monster feet slippers (yes, really) and made my petulant demands. It's still a bit surprising that a mighty tech organ like El Reg doesn't have TLS on the login form(s) though. Just for *ahem* form's sake.
TBH, I wasn't really considering the going site(s)-wide aspect because the point at which it's safe for you to do that and still ship adverts is the point at which it isn't really worth bothering with unless you're living in an exceptionally harsh regime.
> It's [...] a bit surprising that [...] doesn't have TLS on the login form(s) though
And the point of having TLS on the login form only is… to protect your password? Don't reuse passwords across sites, and if that password gets taken by a drive-by on the unsecured wi-fi while you sip your latte, nothing of value is lost.
Create a password with "pwgen 32 1"; copy, paste, login, forget, "reset password" if you ever need to get in again.
Use lastpass or similar if you need to have stronger "security"; use "pass" if you like the command line and are a gpg nut like myself.
Having TLS _only on the login form_ is pretty damn useless because of the above, and what a website should have is have TLS _everywhere_. If it's only on the login form, then an "attacker" sitting behind you while you sip your latte would not be able to sniff your password, but will be able to sniff the authentication cookie - so they'd still be able to post stuff as you, or change your details on account, etc.
So, we either do it _everywhere_ and _properly_ (see things like "https everywhere" and HSTS) or it's IMHO pretty damn useless, security wise - and not really doing it at all.
Should we just enable TLS on the login form to "tick a box", or should we do it everywhere, and do it right? In general, we try to get things right even if it takes a little while longer - whenever possible.
Kinda like a variation of "fast, good, cheap - pick two". Wherever possible, we pick "right", and "even if it takes longer".
Luckily most ads-serving businesses are able to work and provide ads over TLS, so that's a good chunk of work and worry I'm glad we don't have to think about too much. It took time for the industry to get to that point though.
So… it's a matter for us to sit at our mac, sip our favourite @drinks and get on with it. Unfortunately it's not the only task on our plate, and - as I hope to have explained - it's not the most time-sensitive or important one to be done next.
You could be asking a similar question about enabling IPv6 access - also able to be enabled at the touch of a button. You'd get a similar answer: we need to ensure _all_ our sites, processes, programs, what-have-you can handle it. That'll also arrive Soon® :)
A gracious and detailed reply to my somewhat arseoleish initial post.
Even after all you've said, though, it still feels just plain wrong to be handing plaintext passwords over an unsecured connection. And you've got a multiplication factor there of being a news outlet that regularly berates others for plaintext passwords (usually on databases fair enough).
Agreed it doesn't really matter in the grand order of things and I would expect that there aren't too many commentards who are recycling passwords which would be the truly dangerous aspect.
I'll just wait for Soon® to show up then...
"Fucking lucky our commentard accounts on el reg are secure then. Nothin' worse than sending passwords in plaintext. An SSL cert is $10, you cunts. I'll help you install the fucking thing if it's a problem"
The Reg is on Cloudflare, SSL is included free, there's something else going on here.
$ nslookup forums.theregister.co.uk
Server: a.b.c.d
Address: a.b.c.d#53
Non-authoritative answer:
forums.theregister.co.uk canonical name = www.theregister.co.uk.
Name: www.theregister.co.uk
Address: 104.20.25.212
$ whois 104.20.24.212
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# http://www.arin.net/public/whoisinaccuracy/index.xhtml
#
#
# The following results may also be obtained via:
# http://whois.arin.net/rest/nets;q=104.20.24.212?showDetails=true&showARIN=false&showNonArinTopLevelNet=false&ext=netref2
#
NetRange: 104.16.0.0 - 104.31.255.255
CIDR: 104.16.0.0/12
NetName: CLOUDFLARENET
NetHandle: NET-104-16-0-0-1
Parent: NET104 (NET-104-0-0-0-0)
NetType: Direct Assignment
OriginAS: AS13335
Organization: CloudFlare, Inc. (CLOUD14)
RegDate: 2014-03-28
Updated: 2015-10-01
Comment: https://www.cloudflare.com
Ref: http://whois.arin.net/rest/net/NET-104-16-0-0-1
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
