Let us know you when you *actually* block autoplay and when you can do it more like 80+% of the time, like I can do in Firefox right now with the "Disable HTML5 Autoplay" addon.
How would you recommend that each user authenticate himself or herself to the server of Twitter, Slashdot, or any other forum-like web application?
Sending the password
The user provides a password over a TLS channel through a form or HTTP basic authentication, which the server hashes and compares to the stored hash. Most public websites that I'm aware of use this method.
HTTP digest authentication with a fixed realm
The server sends a fixed salt in the realm field, and the user's browser sends the hash of a (username, realm, password) combination to the server. This not only uses the deprecated MD5 algorithm but is also vulnerable to pass the hash attacks.
HTTP digest authentication with a variable realm
The server sends an IV in the realm field, and the user's browser sends the hash of a (username, realm, password) combination to the server. This not only uses the deprecated MD5 algorithm but also requires the server to store the password (not just a hash thereof) in order to verify that the hash is correct.
Some zero-knowledge proof means
Because a zero-knowledge proof isn't defined in the HTTP spec, it requires the user to download a program from Twitter's server and execute it on his or her computer. This fails if the user has turned off automatic execution of script in the browser.
Using a client certificate
TLS allows a user agent to identify itself using a certificate, much as with an SSH client key. But its usability in current web browsers is so terrible that I can think of only two websites that have used it: StartSSL (RIP) and Kount (an e-commerce fraud detection service).
Some option that I haven't thought of
I'd be interested to read your reply describing such a method.
The passwords are not transmitted in plain text; they are transmitted through a TLS channel. The storage was intended to be as a bcrypt hash value, not as plaintext or even as ciphertext. The storage described in the featured article was a mistake apparently during debugging, which was discovered and corrected, presumably before the result could leak.
One slight correction: Your list included AM2R, a port of Metroid II. Metroid II is a first-party Game Boy game from Nintendo, which was released when Nintendo dominated handheld video gaming. That looks way more AAA than indie to me. Had it instead been an original IP, it would have been indie.
Nobody's stopping you from putting up your own website and hosting your videos there.
Other than lack of $4,000 for a guide describing effective methods of finding and negotiating with potential advertisers the way a local TV station has to, as you quoted in this comment.
Read the summary. The "mobile" figure is "including smartphones and tablets, but not dedicated gaming handhelds" such as the Nintendo 3DS and PlayStation Vita.
In fact, there's a whole slew of great mobile games that won't translate well to a controller - the likes of Jetpack Joyride, Collossotron, Threes, plenty of table games etc.
Jetpack Joyride is a flappy game, and flappy games are ultimately clones of the "Balloon Trip" mode in Balloon Fight for the Nintendo Entertainment System. There's a Threes clone for NES by tsone, titled 2048. I had to look up Colossatron, and everything I see in a gameplay video looks doable with a mouse, an analog stick, a Nintendo 3DS touch screen, or a Wii Remote.
And it's perfectly fine - the best games on any platform make use of the platform's best features and try not to imitate features that don't exist
In other words, one- or two-button or point-and-click games. Game designs under that restriction have on the whole tended to be more shallow than games using a keyboard or a gamepad.
Game Boy, Game Boy Color, and Game Boy Advance cartridges have no cryptographic "digital restrictions management" as that term is understood today. The boot ROM just checks for a header ($0104-$014F on GB/GBC, $000000-$0000BF on GBA) that has a valid checksum and some typography in it. Nintendo handhelds didn't start using DRM until the DS, which encrypts the cart edge interface using Blowfish.
"JavaScript is enabled, but I use LibreJS to block proprietary script. Can you send me a copy of the authentication script's unobfuscated, unminified source code under a free software license so that I (or another member) can perform a code review before executing it?"
A better question is why doesn't the HTML standard for password fields allow automatic hashing with a custom salt?
It does; it's called digest authentication. But depending on how digest authentication is implemented, it is vulnerable to one of two attacks. If the realm portion is fixed, digest is vulnerable to a replay attack that passes the hash. If the realm portion is variable, it requires the server to store the unhashed password. In addition, digest authentication still uses MD5, which is deprecated and whose immediate successor (SHA-1) is also deprecated.
Basic auth is an HTTP header, and HTTP headers are just as protected by TLS as response headers and bodies. Otherwise, HTTPS would be ineffective against Firesheep-style attacks that clone a session cookie. The other common means of authentication is submitting a password that has been entered into a field of an HTML form as part of an HTTP POST request body. What's any more "in the clear" with HTTP basic authentication than with the form route?
And in case you believe both forms and basic authentication ought to be replaced, what other means would you prefer? I can think of three, each with serious drawbacks:
HTTP Digest authentication
This does hashing using a random initialization vector. However, it requires the server to store the password rather than only an irreversible hash for verification.
Some zero-knowledge proof means
Because this is not built into the HTML5 standard, it requires running script in the browser. Though web browsers by default run all scripts, many users change this for security and data cap reasons. Extensions exist to restrict script execution to a domain whitelist (JavaScript Switcher), a fine-grained whitelist (NoScript), or only those scripts whose source code is machine-readably available to the public under a free software license (LibreJS). Some go so far as to regularly browse the web with all scripts turned off.
Client certificates
TLS supports the use of a client certificate that identifies a user, which is exactly analogous to key-based authentication in SSH. However, browser publishers have thus far given no significant attention to usability of common use cases, such as choosing the right client certificate for a particular origin, synchronizing client certificates across devices that a user uses, or even something as simple as logging out.
Owning insecure wire between name server and Internet.
If you own the only wire between the primary name server and the Internet, the CA will notice that the TXT records on the primary name server do not notice the TXT records on the secondary name server.
Why would I bother with LE when I can get a 3 year cert from a normal CA using exactly the same approach?
Not needing to whip out your credit card for every hostname that you control.
The policy change described in the featured article encourages CAs to keep their CT logs complete.
Safe bet they won't.
If CAs don't use CT, then as described in the featured article, users of Google Chrome will not be able to use HTTPS on websites using certificates from those CAs, causing web server administrators to seek refunds from said CAs. Is processing a ton of refunds really cheaper than implementing CT?
Develop, or fund the development of, a free replacement for said non-free app. Or file a support ticket with the application's publisher to whitelist your company's internal server's certificate in a customized build of the application for your company.
Slashdot Mirror
Let us know you when you *actually* block autoplay and when you can do it more like 80+% of the time, like I can do in Firefox right now with the "Disable HTML5 Autoplay" addon.
Does your autoplay blocker also block motion JPEG implemented in pure CSS?
The few things you mention slip through on some unobnoxious videos, and are mild compared to the effect of having audio suddenly playing.
It's not "mild" when you get the data use overage bill at the end of the month.
Would you prefer that websites fall back from muted autoplaying WebM to muted autoplaying GIF animation, which requires a higher bitrate than WebM?
How would you recommend that each user authenticate himself or herself to the server of Twitter, Slashdot, or any other forum-like web application?
Sending the password The user provides a password over a TLS channel through a form or HTTP basic authentication, which the server hashes and compares to the stored hash. Most public websites that I'm aware of use this method. HTTP digest authentication with a fixed realm The server sends a fixed salt in the realm field, and the user's browser sends the hash of a (username, realm, password) combination to the server. This not only uses the deprecated MD5 algorithm but is also vulnerable to pass the hash attacks. HTTP digest authentication with a variable realm The server sends an IV in the realm field, and the user's browser sends the hash of a (username, realm, password) combination to the server. This not only uses the deprecated MD5 algorithm but also requires the server to store the password (not just a hash thereof) in order to verify that the hash is correct. Some zero-knowledge proof means Because a zero-knowledge proof isn't defined in the HTTP spec, it requires the user to download a program from Twitter's server and execute it on his or her computer. This fails if the user has turned off automatic execution of script in the browser. Using a client certificate TLS allows a user agent to identify itself using a certificate, much as with an SSH client key. But its usability in current web browsers is so terrible that I can think of only two websites that have used it: StartSSL (RIP) and Kount (an e-commerce fraud detection service). Some option that I haven't thought of I'd be interested to read your reply describing such a method.The passwords are not transmitted in plain text; they are transmitted through a TLS channel. The storage was intended to be as a bcrypt hash value, not as plaintext or even as ciphertext. The storage described in the featured article was a mistake apparently during debugging, which was discovered and corrected, presumably before the result could leak.
This is why I have been saying for years Javascript as GOT to go.
Would you prefer a form submission and full page reload for every action that you perform in a web application?
IDK if we should go to a locked sandbox with very limited tools
That's what JavaScript was supposed to be.
Many companies offer, as an employee retention perk, the privilege to use company equipment for personal web browsing while on break.
I never meant to imply that the correlation was perfect, just noticeably greater than chance.
without Nintendo's permission.
Which is why I cannot count it.
One slight correction: Your list included AM2R, a port of Metroid II. Metroid II is a first-party Game Boy game from Nintendo, which was released when Nintendo dominated handheld video gaming. That looks way more AAA than indie to me. Had it instead been an original IP, it would have been indie.
Nobody's stopping you from putting up your own website and hosting your videos there.
Other than lack of $4,000 for a guide describing effective methods of finding and negotiating with potential advertisers the way a local TV station has to, as you quoted in this comment.
Read the summary. The "mobile" figure is "including smartphones and tablets, but not dedicated gaming handhelds" such as the Nintendo 3DS and PlayStation Vita.
In fact, there's a whole slew of great mobile games that won't translate well to a controller - the likes of Jetpack Joyride, Collossotron, Threes, plenty of table games etc.
Jetpack Joyride is a flappy game, and flappy games are ultimately clones of the "Balloon Trip" mode in Balloon Fight for the Nintendo Entertainment System. There's a Threes clone for NES by tsone, titled 2048 . I had to look up Colossatron, and everything I see in a gameplay video looks doable with a mouse, an analog stick, a Nintendo 3DS touch screen, or a Wii Remote.
And it's perfectly fine - the best games on any platform make use of the platform's best features and try not to imitate features that don't exist
In other words, one- or two-button or point-and-click games. Game designs under that restriction have on the whole tended to be more shallow than games using a keyboard or a gamepad.
Game Boy, Game Boy Color, and Game Boy Advance cartridges have no cryptographic "digital restrictions management" as that term is understood today. The boot ROM just checks for a header ($0104-$014F on GB/GBC, $000000-$0000BF on GBA) that has a valid checksum and some typography in it. Nintendo handhelds didn't start using DRM until the DS, which encrypts the cart edge interface using Blowfish.
Google Search for commercial speech returned the Wikipedia article "Commercial speech" that led me to Central Hudson Gas & Electric Corp. v. Public Service Commission, 447 U.S. 557 (1980), which instituted a four-step test to determine whether regulation of commercial speech is constitutional. In particular, commercial speech is protected only when it is not misleading.
The closest is probably Secure Remote Password, as TheRaven64 pointed out.
"JavaScript is enabled, but I use LibreJS to block proprietary script. Can you send me a copy of the authentication script's unobfuscated, unminified source code under a free software license so that I (or another member) can perform a code review before executing it?"
If the answer is no, then this is why GitHub has been rated F for requiring execution of proprietary script.
USE KEY-DERIVATION FUNCTIONS (KDF) INSTEAD !
Like the Bcrypt use by github as mentionned in the summary. Or Scrypt (same used by tarsnap). Or Argon2. etc.
Is SHA256 inside PBKDF2 still safe?
A better question is why doesn't the HTML standard for password fields allow automatic hashing with a custom salt?
It does; it's called digest authentication. But depending on how digest authentication is implemented, it is vulnerable to one of two attacks. If the realm portion is fixed, digest is vulnerable to a replay attack that passes the hash. If the realm portion is variable, it requires the server to store the unhashed password. In addition, digest authentication still uses MD5, which is deprecated and whose immediate successor (SHA-1) is also deprecated.
Basic auth is an HTTP header, and HTTP headers are just as protected by TLS as response headers and bodies. Otherwise, HTTPS would be ineffective against Firesheep-style attacks that clone a session cookie. The other common means of authentication is submitting a password that has been entered into a field of an HTML form as part of an HTTP POST request body. What's any more "in the clear" with HTTP basic authentication than with the form route?
And in case you believe both forms and basic authentication ought to be replaced, what other means would you prefer? I can think of three, each with serious drawbacks:
HTTP Digest authentication This does hashing using a random initialization vector. However, it requires the server to store the password rather than only an irreversible hash for verification. Some zero-knowledge proof means Because this is not built into the HTML5 standard, it requires running script in the browser. Though web browsers by default run all scripts, many users change this for security and data cap reasons. Extensions exist to restrict script execution to a domain whitelist (JavaScript Switcher), a fine-grained whitelist (NoScript), or only those scripts whose source code is machine-readably available to the public under a free software license (LibreJS). Some go so far as to regularly browse the web with all scripts turned off. Client certificates TLS supports the use of a client certificate that identifies a user, which is exactly analogous to key-based authentication in SSH. However, browser publishers have thus far given no significant attention to usability of common use cases, such as choosing the right client certificate for a particular origin, synchronizing client certificates across devices that a user uses, or even something as simple as logging out.If you have users who turn off JavaScript-by-default for security reasons or software freedom reasons, how do you hash on the client side?
Owning insecure wire between name server and Internet.
If you own the only wire between the primary name server and the Internet, the CA will notice that the TXT records on the primary name server do not notice the TXT records on the secondary name server.
Why would I bother with LE when I can get a 3 year cert from a normal CA using exactly the same approach?
Not needing to whip out your credit card for every hostname that you control.
The policy change described in the featured article encourages CAs to keep their CT logs complete.
Safe bet they won't.
If CAs don't use CT, then as described in the featured article, users of Google Chrome will not be able to use HTTPS on websites using certificates from those CAs, causing web server administrators to seek refunds from said CAs. Is processing a ton of refunds really cheaper than implementing CT?
And if they’re apps that are not open source
Develop, or fund the development of, a free replacement for said non-free app. Or file a support ticket with the application's publisher to whitelist your company's internal server's certificate in a customized build of the application for your company.
How is an end user supposed to know where on the sliding scale a particular site is supposed to sit?
I have access to wires over which DNS flows
How many routes do you control? Good luck gaining control of all routes belonging to the CA or all routes belonging to both name servers.