• Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Normal Normal
    • 2013-07-22
    • None
    • Accounts, Admin

      The page where a user submits their username and password should be handled through HTTPS, to reduce the chance of username and passwords being intercepted, particularly when users are logging in at public hotspots over WiFi.

      Given that other sites like GMail and Facebook are now encrypting their entire traffic to overcome Firesheep (http://en.wikipedia.org/wiki/Firesheep) session cookie cloning attacks, it's seems very poor practice that passwords are being sent apparently in plain text.

          [MBS-2411] Login page should be encrypted (SSL/TLS)

          Kuno Woudt added a comment -

          Setting fix version to next release.

          This has been enabled on beta.musicbrainz.org, if it doesn't cause any problems there it should be enabled on production during the release.

          Kuno Woudt added a comment - Setting fix version to next release. This has been enabled on beta.musicbrainz.org, if it doesn't cause any problems there it should be enabled on production during the release.

          Ian McEwen added a comment -

          I am also removing the fix version – this needs to go forward, but it's definitely not in the next release.

          Ian McEwen added a comment - I am also removing the fix version – this needs to go forward, but it's definitely not in the next release.

          Ian McEwen added a comment -

          I don't know why this is marked as in review, but it's not, so I'm pulling it out

          Ian McEwen added a comment - I don't know why this is marked as in review, but it's not, so I'm pulling it out

          This is in review, but there is no open review. Status update please!

          Oliver Charles added a comment - This is in review, but there is no open review. Status update please!

          Kuno Woudt added a comment -

          Kuno Woudt added a comment - http://codereview.musicbrainz.org/r/2450/

          Kuno Woudt added a comment -

          TODO on this ticket:

          force SSL for login and registration.

          Kuno Woudt added a comment - TODO on this ticket: force SSL for login and registration.

          Ian McEwen added a comment -

          SSL is now available on production. There's at least one issue still, in that https://www.musicbrainz.org (in some situations) will redirect to non-SSL (http://codereview.musicbrainz.org/r/2395/) but the certificate is deployed and ready! SSL Labs test: https://www.ssllabs.com/ssltest/analyze.html?d=musicbrainz.org

          Ian McEwen added a comment - SSL is now available on production. There's at least one issue still, in that https://www.musicbrainz.org (in some situations) will redirect to non-SSL ( http://codereview.musicbrainz.org/r/2395/ ) but the certificate is deployed and ready! SSL Labs test: https://www.ssllabs.com/ssltest/analyze.html?d=musicbrainz.org

          The window for shipping this to beta testing has closed, so this will have to wait for the next release.

          Oliver Charles added a comment - The window for shipping this to beta testing has closed, so this will have to wait for the next release.

          Sadly there's a little more to do until we can ship this, so I'm pushing it to the next version.

          Oliver Charles added a comment - Sadly there's a little more to do until we can ship this, so I'm pushing it to the next version.

          Ian McEwen added a comment -

          https://www.ssllabs.com/ssltest/analyze.html?d=test.musicbrainz.org is the test page; the BEAST warning has to do with the fact we have a CBC ciphersuite listed first – and browsers have good workarounds for BEAST anyway. So, this is looking pretty good!

          Ian McEwen added a comment - https://www.ssllabs.com/ssltest/analyze.html?d=test.musicbrainz.org is the test page; the BEAST warning has to do with the fact we have a CBC ciphersuite listed first – and browsers have good workarounds for BEAST anyway. So, this is looking pretty good!

          Ian McEwen added a comment -

          (testing: logging in using SSL and then going back to non-SSL does work as it should)

          Ian McEwen added a comment - (testing: logging in using SSL and then going back to non-SSL does work as it should)

          Ian McEwen added a comment -

          Note to all: test.musicbrainz.org is now running with a non-self-signed cert; MBS-5301 is in review to make gravatars get loaded over SSL, wikidocs are trying to load over SSL but that won't work until MBH-281 is done (yes, yes, I'm working on it...). No bugs opened yet for coverart, which we'll need to switch to use SSL where we can. Other thing we'll need to do is (probably) force SSL for login, and make sure that SSL logins/cookies/etc. still work on non-SSL.

          Ian McEwen added a comment - Note to all: test.musicbrainz.org is now running with a non-self-signed cert; MBS-5301 is in review to make gravatars get loaded over SSL, wikidocs are trying to load over SSL but that won't work until MBH-281 is done (yes, yes, I'm working on it...). No bugs opened yet for coverart, which we'll need to switch to use SSL where we can. Other thing we'll need to do is (probably) force SSL for login, and make sure that SSL logins/cookies/etc. still work on non-SSL.

          Robert Kaye added a comment -

          I've purchased the cert and we're pretty much ready to go once we're happy with test/beta. What else do I need to do?

          Robert Kaye added a comment - I've purchased the cert and we're pretty much ready to go once we're happy with test/beta. What else do I need to do?

          The due date of this ticket is 11/Sep/12. This won't make the next release (2012-09-17) because we're in freeze, so the earliest this can make it is (2012-10-01). I've assigned to Rob to make sure that we get this done!

          Oliver Charles added a comment - The due date of this ticket is 11/Sep/12. This won't make the next release (2012-09-17) because we're in freeze, so the earliest this can make it is (2012-10-01). I've assigned to Rob to make sure that we get this done!

          intgr added a comment -

          > TL;DR. Get an 8 to 15 dollar per year standard SSL certificate for musicbrainz.org first, worry about anything else after we've implemented that successfully.

          I don't mean to spam here, but I think it's worth considering StartSSL (www.startssl.com).

          They offer free 1-year domain-validated certificates, covering the main domain and one subdomain of your choice (e.g. musicbrainz.org and foo.musicbrainz.org); no strings attached – free renewals allowed, too. I think you can get multiple of these to cover all subdomains, although maintenance would be a PITA.

          They also wildcard certificates at reasonable prices, $60 for personal validation (e.g. registrant's personal name will be published in the certificate) and $60+60 for organization; these certificates are good for 2 years.

          More details: https://www.startssl.com/?app=40

          intgr added a comment - > TL;DR. Get an 8 to 15 dollar per year standard SSL certificate for musicbrainz.org first, worry about anything else after we've implemented that successfully. I don't mean to spam here, but I think it's worth considering StartSSL (www.startssl.com). They offer free 1-year domain-validated certificates, covering the main domain and one subdomain of your choice (e.g. musicbrainz.org and foo.musicbrainz.org); no strings attached – free renewals allowed, too. I think you can get multiple of these to cover all subdomains, although maintenance would be a PITA. They also wildcard certificates at reasonable prices, $60 for personal validation (e.g. registrant's personal name will be published in the certificate) and $60+60 for organization; these certificates are good for 2 years. More details: https://www.startssl.com/?app=40

          Kuno Woudt added a comment -

          Some of us would have liked to go for https:// all the time, but that will likely break a bunch of stuff (including userscripts). So we must ship with both https:// and http:// working.

          Discussion here: http://chatlogs.musicbrainz.org/musicbrainz-devel/2012/2012-08/2012-08-16.html#T09-56-08-127412

          Kuno Woudt added a comment - Some of us would have liked to go for https:// all the time, but that will likely break a bunch of stuff (including userscripts). So we must ship with both https:// and http:// working. Discussion here: http://chatlogs.musicbrainz.org/musicbrainz-devel/2012/2012-08/2012-08-16.html#T09-56-08-127412

          Robert Kaye added a comment -

          Now we need to use scheme relative links to get the site to work. https support is now available for test.mb.org (self signed) and will soon be available for musicbrainz.org (proper cert)

          Robert Kaye added a comment - Now we need to use scheme relative links to get the site to work. https support is now available for test.mb.org (self signed) and will soon be available for musicbrainz.org (proper cert)

          Robert Kaye added a comment -

          We've purchased a two year certificate and I've turned this certificate over to djce. He's playing with setting up nginx as we speak.

          Robert Kaye added a comment - We've purchased a two year certificate and I've turned this certificate over to djce. He's playing with setting up nginx as we speak.

          If you're looking at EV certs, Verisign is rediculously expensive - something like $1200 US per cert. However, Steve Gibson has recommended DigiCert; he's had good luck there, and they're far cheaper. http://www.digicert.com/ev-ssl-certification.htm $469 for 2 years for one domain, or $779 for 2 years for three domains. (I think MB would only need the one domain). (Ref http://www.grc.com/sn/sn-359.htm ; search "And this is DigiCert once again.").

          Brian Schweitzer added a comment - If you're looking at EV certs, Verisign is rediculously expensive - something like $1200 US per cert. However, Steve Gibson has recommended DigiCert; he's had good luck there, and they're far cheaper. http://www.digicert.com/ev-ssl-certification.htm $469 for 2 years for one domain, or $779 for 2 years for three domains. (I think MB would only need the one domain). (Ref http://www.grc.com/sn/sn-359.htm ; search "And this is DigiCert once again.").

          Ian McEwen added a comment -

          I think that ultimately we should get an EV cert if we think it's affordable enough – but starting with a basic one, for mb.org only, would be acceptable IMO for this ticket.

          Ian McEwen added a comment - I think that ultimately we should get an EV cert if we think it's affordable enough – but starting with a basic one, for mb.org only, would be acceptable IMO for this ticket.

          Kuno Woudt added a comment - - edited

          TL;DR. Get an 8 to 15 dollar per year standard SSL certificate for musicbrainz.org first, worry about anything else after we've implemented that successfully.

          More detailed:

          Ian is correct in saying that a *.musicbrainz.org certificate cannot be used for musicbrainz.org itself. So we always need at least two or more separate certificates or a certificate with multiple names (subjectAltNames).

          subjectAltName is supported by all browsers I believe, but may not be supported in all client libraries – so this could be a problem for webservice clients which need to do authentication (considering we don't have oauth yet). For example, the wget in Ubuntu still has issues with it (I haven't tested this myself, the bug report is here: https://bugs.launchpad.net/ubuntu/+source/wget/+bug/733888).

          I would prefer a wildcard certificate over a certificate with subjectAltNames for that reason, and it also gives us a lot more flexibility when deploying stuff on new subdomains.

          I think we should just start with a standard musicbrainz.org certificate (EUR 12/year at gandi). A wildcard or subjectAltName certificate is usually far more expensive (wildcard at gandi is EUR 120/year, subjectAltName starts at EUR 265/year it seems). Once we have musicbrainz.org implemented on a standard ssl certificate, we can worry about what to do with the subdomains and which certificates we need for it.

          To get a better idea for US-based prices, have a look at https://www.namecheap.com/ssl-certificates/comodo.aspx . Namecheap lets you choose from which certificate authority you get the certificate, they're all trusted by current browsers so there is fairly little value in picking e.g. verisign over comodo.

          Kuno Woudt added a comment - - edited TL;DR. Get an 8 to 15 dollar per year standard SSL certificate for musicbrainz.org first, worry about anything else after we've implemented that successfully. More detailed: Ian is correct in saying that a *.musicbrainz.org certificate cannot be used for musicbrainz.org itself. So we always need at least two or more separate certificates or a certificate with multiple names (subjectAltNames). subjectAltName is supported by all browsers I believe, but may not be supported in all client libraries – so this could be a problem for webservice clients which need to do authentication (considering we don't have oauth yet). For example, the wget in Ubuntu still has issues with it (I haven't tested this myself, the bug report is here: https://bugs.launchpad.net/ubuntu/+source/wget/+bug/733888 ). I would prefer a wildcard certificate over a certificate with subjectAltNames for that reason, and it also gives us a lot more flexibility when deploying stuff on new subdomains. I think we should just start with a standard musicbrainz.org certificate (EUR 12/year at gandi). A wildcard or subjectAltName certificate is usually far more expensive (wildcard at gandi is EUR 120/year, subjectAltName starts at EUR 265/year it seems). Once we have musicbrainz.org implemented on a standard ssl certificate, we can worry about what to do with the subdomains and which certificates we need for it. To get a better idea for US-based prices, have a look at https://www.namecheap.com/ssl-certificates/comodo.aspx . Namecheap lets you choose from which certificate authority you get the certificate, they're all trusted by current browsers so there is fairly little value in picking e.g. verisign over comodo.

          Ian McEwen added a comment - - edited

          A wildcard of the format

          *.musicbrainz.org

          would do everything except musicbrainz.org itself (https://en.wikipedia.org/wiki/Wildcard_SSL_certificate). Wildcards also prevent getting EV certificates; I don't know whether or not we care about that. I do agree that we want to secure our subdomains as well though, especially since there are likely so many shared passwords. An option (listed on the linked page) is to manually list all the relevant subjectAltName entries within the certificate.

          My vote would be for an extended-validation (EV) certificate using the subjectAltName extension to list our various subdomains (which we should have a list of somewhere, I imagine?).

          A good read is also http://www.imperialviolet.org/2012/07/19/hope9talk.html

          Ian McEwen added a comment - - edited A wildcard of the format *.musicbrainz.org would do everything except musicbrainz.org itself ( https://en.wikipedia.org/wiki/Wildcard_SSL_certificate ). Wildcards also prevent getting EV certificates; I don't know whether or not we care about that. I do agree that we want to secure our subdomains as well though, especially since there are likely so many shared passwords. An option (listed on the linked page) is to manually list all the relevant subjectAltName entries within the certificate. My vote would be for an extended-validation (EV) certificate using the subjectAltName extension to list our various subdomains (which we should have a list of somewhere, I imagine?). A good read is also http://www.imperialviolet.org/2012/07/19/hope9talk.html

          I would think wildcard, so we can use them on all our other services (forums, tickets, etc). That'd be due to me being in the HTTPS everywhere camp.

          Oliver Charles added a comment - I would think wildcard, so we can use them on all our other services (forums, tickets, etc). That'd be due to me being in the HTTPS everywhere camp.

          Robert Kaye added a comment -

          Agreed, lets move on this.

          However, it is not clear which certificates I should get. Do I get a *.musicbrainz certificate or just a musicbrainz.org certificate? Assigning to warp who seems to have a decent grasp on this.

          Robert Kaye added a comment - Agreed, lets move on this. However, it is not clear which certificates I should get. Do I get a *.musicbrainz certificate or just a musicbrainz.org certificate? Assigning to warp who seems to have a decent grasp on this.

          This is blocked on certificates and stuff, so I'm assigning to Rob who is the only person who can help with that.

          Oliver Charles added a comment - This is blocked on certificates and stuff, so I'm assigning to Rob who is the only person who can help with that.

          Oliver Charles added a comment - Agreed to fix within 3 months by http://scheduling.ocharles.org.uk/results and http://chatlogs.musicbrainz.org/musicbrainz-devel/2012/2012-06/2012-06-11.html

          Screenshot shows an example of how an 'intercepted' Musicbrainz login request looks, containing in plain text both the username and password submitted through the login page (helpfully labelled up as such too!)

          Cerdd Eightythree added a comment - Screenshot shows an example of how an 'intercepted' Musicbrainz login request looks, containing in plain text both the username and password submitted through the login page (helpfully labelled up as such too!)

          This sort of thing seems to be in the news again recently with LinkedIn, last.fm & eHarmony. I appreciate there's a difference in how those passwords were seemingly obtained, but in all those cases passwords were at least taken in encrypted form, so there is some protection for those using relatively strong and unique passwords. MBz passwords are still being sent, never mind stored, in the clear so no matter how good a password, if intercepted it's there for all to see. Given that many users reuse passwords, and once logged in the users email address is accessible, although there is little to be gained from accessing a MBz account alone, once a users' email is accessible, access to most websites registered with that email address can be found and/or reset.

          Cerdd Eightythree added a comment - This sort of thing seems to be in the news again recently with LinkedIn, last.fm & eHarmony. I appreciate there's a difference in how those passwords were seemingly obtained, but in all those cases passwords were at least taken in encrypted form, so there is some protection for those using relatively strong and unique passwords. MBz passwords are still being sent, never mind stored, in the clear so no matter how good a password, if intercepted it's there for all to see. Given that many users reuse passwords, and once logged in the users email address is accessible, although there is little to be gained from accessing a MBz account alone, once a users' email is accessible, access to most websites registered with that email address can be found and/or reset.

            warp Kuno Woudt
            Anonymous Anonymous
            Votes:
            9 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved:

                Version Package
                2013-07-22