Talk:1700: New Bug - Revision history

108.162.219.174 at 21:31, 24 July 2021

2021-07-24T21:31:14Z

Davidy22 at 21:14, 15 October 2016

2016-10-15T21:14:56Z

Gunterkoenigsmann: An alternative idea about how big the problem might be.

2016-10-15T07:13:16Z

An alternative idea about how big the problem might be.

Jonsku99 at 12:30, 26 July 2016

2016-07-26T12:30:59Z

162.158.255.113 at 22:03, 5 July 2016

2016-07-05T22:03:12Z

162.158.85.147: Added Firefox codemoji infos

2016-07-04T09:58:51Z

Added Firefox codemoji infos

Davidy22 at 14:47, 1 July 2016

2016-07-01T14:47:33Z

Cmancone at 12:58, 1 July 2016

2016-07-01T12:58:38Z

Cmancone at 12:43, 1 July 2016

2016-07-01T12:43:49Z

Pmakholm at 12:09, 1 July 2016

2016-07-01T12:09:27Z

← Older revision		Revision as of 21:31, 24 July 2021
Line 47:		Line 47:

	I think the real horror of this bug has not been addressed in the description above: In order to check if a password is a resolvable domain name it has to be sent to a domain name server - and the connection to the next domain name server is traditionally completely unencrypted => The system's ability to check if the password is a resolvable URL implies that all passwords might be known to everyone who has access to a piece of the internet infrastructure. Things cannot get much worse to a sysadmin than this - except perhaps for later finding the leaked passwords for sale in a public place, that is. [[User:Gunterkoenigsmann\|Gunterkoenigsmann]] ([[User talk:Gunterkoenigsmann\|talk]]) 07:10, 15 October 2016 (UTC)		I think the real horror of this bug has not been addressed in the description above: In order to check if a password is a resolvable domain name it has to be sent to a domain name server - and the connection to the next domain name server is traditionally completely unencrypted => The system's ability to check if the password is a resolvable URL implies that all passwords might be known to everyone who has access to a piece of the internet infrastructure. Things cannot get much worse to a sysadmin than this - except perhaps for later finding the leaked passwords for sale in a public place, that is. [[User:Gunterkoenigsmann\|Gunterkoenigsmann]] ([[User talk:Gunterkoenigsmann\|talk]]) 07:10, 15 October 2016 (UTC)
		+	: Correct me if I'm wrong, but doesn't DNS resolution only send the domain name to the DNS server, not the entire URL? [[Special:Contributions/108.162.219.174\|108.162.219.174]] 21:31, 24 July 2021 (UTC)

@@ Line 1: / Line 1: @@
 <!--Please sign your posts with ~~~~-->
 I'm new. For the explanation: A bug, as in a computer (programming) bug, can be reported and tracked, and many systems allow collaboration on the reporting and tracking of problems, or bugs, in code, and their solutions. Cueball reported a problem (bug) he found in the code, which presumably caused the server (program)&mdash;which he wrote as part of his project&mdash;to try to read the passwords as URLs before storing them. This exposes serious cross-site scripting attacks and other serious security vulnerabilities, and since handling password and user account information usually requires a lot of programming, this would be difficult to fix, which is why the character off-panel suggests burning the project down, as that would be much easier, and would solve any security problems, much more quickly than fixing the bug would. The comment text refers to Cueball's horrid solution to a horrid problem: Instead of solving the problem that is causing the server to read passwords as URLs, he can instead leverage a known problem in the programme which reads URLs which prevents it from reading a particular way of representing text in binary form, by adding a few characters to the user's password that the URL-reading program can't read. This would also "salt" the user's password, which is a security technique that makes passwords harder to figure out when they are stored properly. Cueball thinks this would solve the original problem, and two other problems at the same time, the second problem being the fact that user's passwords aren't salted (a security problem). The third solved problem is difficult to deduce.   &emsp;[[User:Zyzygy|Zyzygy]] 05:40, 29 June 2016 (UTC)
@@ Line 46: / Line 44: @@
 A good addition could be that the passwords were most probably stored in plaintext, which is even worse. [[User:Jonsku99|Jonsku99]] ([[User talk:Jonsku99|talk]]) 12:30, 26 July 2016 (UTC)

← Older revision		Revision as of 07:13, 15 October 2016
Line 1:		Line 1:
	<!--Please sign your posts with ~~~~-->		<!--Please sign your posts with ~~~~-->
		+	I think the real horror of this bug has not been addressed in the description above: In order to check if a password is a resolvable domain name it has to be sent to a domain name server - and the connection to the next domain name server is traditionally completely unencrypted => The system's ability to check if the password is a resolvable URL implies that all passwords might be known to everyone who has access to a piece of the internet infrastructure. Things cannot get much worse to a sysadmin than this - except perhaps for later finding the leaked passwords for sale in a public place, that is. [[User:Gunterkoenigsmann\|Gunterkoenigsmann]] ([[User talk:Gunterkoenigsmann\|talk]]) 07:10, 15 October 2016 (UTC)
		+
	I'm new. For the explanation: A bug, as in a computer (programming) bug, can be reported and tracked, and many systems allow collaboration on the reporting and tracking of problems, or bugs, in code, and their solutions. Cueball reported a problem (bug) he found in the code, which presumably caused the server (program)—which he wrote as part of his project—to try to read the passwords as URLs before storing them. This exposes serious cross-site scripting attacks and other serious security vulnerabilities, and since handling password and user account information usually requires a lot of programming, this would be difficult to fix, which is why the character off-panel suggests burning the project down, as that would be much easier, and would solve any security problems, much more quickly than fixing the bug would. The comment text refers to Cueball's horrid solution to a horrid problem: Instead of solving the problem that is causing the server to read passwords as URLs, he can instead leverage a known problem in the programme which reads URLs which prevents it from reading a particular way of representing text in binary form, by adding a few characters to the user's password that the URL-reading program can't read. This would also "salt" the user's password, which is a security technique that makes passwords harder to figure out when they are stored properly. Cueball thinks this would solve the original problem, and two other problems at the same time, the second problem being the fact that user's passwords aren't salted (a security problem). The third solved problem is difficult to deduce. &emsp;[[User:Zyzygy\|Zyzygy]] 05:40, 29 June 2016 (UTC)		I'm new. For the explanation: A bug, as in a computer (programming) bug, can be reported and tracked, and many systems allow collaboration on the reporting and tracking of problems, or bugs, in code, and their solutions. Cueball reported a problem (bug) he found in the code, which presumably caused the server (program)—which he wrote as part of his project—to try to read the passwords as URLs before storing them. This exposes serious cross-site scripting attacks and other serious security vulnerabilities, and since handling password and user account information usually requires a lot of programming, this would be difficult to fix, which is why the character off-panel suggests burning the project down, as that would be much easier, and would solve any security problems, much more quickly than fixing the bug would. The comment text refers to Cueball's horrid solution to a horrid problem: Instead of solving the problem that is causing the server to read passwords as URLs, he can instead leverage a known problem in the programme which reads URLs which prevents it from reading a particular way of representing text in binary form, by adding a few characters to the user's password that the URL-reading program can't read. This would also "salt" the user's password, which is a security technique that makes passwords harder to figure out when they are stored properly. Cueball thinks this would solve the original problem, and two other problems at the same time, the second problem being the fact that user's passwords aren't salted (a security problem). The third solved problem is difficult to deduce. &emsp;[[User:Zyzygy\|Zyzygy]] 05:40, 29 June 2016 (UTC)

← Older revision		Revision as of 12:30, 26 July 2016
Line 42:		Line 42:

	Around the time this comic was published, Firefox linked on its start-page to https://advocacy.mozilla.org/en-US/encrypt/codemoji/2, where a webapp Codeempji is available. With this webapp one can use emojis to scramble messages with a Caesar-cipher like method. This might be the reason for the emoji reference in the title text.[[Special:Contributions/162.158.85.147\|162.158.85.147]] 09:58, 4 July 2016 (UTC)		Around the time this comic was published, Firefox linked on its start-page to https://advocacy.mozilla.org/en-US/encrypt/codemoji/2, where a webapp Codeempji is available. With this webapp one can use emojis to scramble messages with a Caesar-cipher like method. This might be the reason for the emoji reference in the title text.[[Special:Contributions/162.158.85.147\|162.158.85.147]] 09:58, 4 July 2016 (UTC)
		+
		+	A good addition could be that the passwords were most probably stored in plaintext, which is even worse. [[User:Jonsku99\|Jonsku99]] ([[User talk:Jonsku99\|talk]]) 12:30, 26 July 2016 (UTC)

@@ Line 16: / Line 16: @@
 :::Writing an extension to your language of choice would probably be a good way of crashing the server, although I would say that writing extensions to the language itself is not a common thing for most people to do.  I suppose I'm arguing from experience (which is not always accurate) but in years of PHP and python programming I've never once had to write a language extension, nor did I ever need to for my very complicated thesis work.  So I would say that the general point still stands: if Cueball is crashing any part of the server, he is doing things very wrong or at least very different.[[User:Cmancone|Cmancone]] ([[User talk:Cmancone|talk]]) 12:58, 1 July 2016 (UTC)
 Regarding those last two points: sorry for my long unsigned rant.  Didn't realize I wasn't logged in.  Still haven't figured out how to sign comments.  Gonna try it this time. [[User:Cmancone|Cmancone]] ([[User talk:Cmancone|talk]]) 16:51, 29 June 2016 (UTC)
@@ Line 23: / Line 25: @@
 :I think http://xkcd.com/correct/horse/battery/staple/ would be a perfectly fine password, even though it is also an URL – but a heuristic that just looks at the length of the password and if it only contains alphanumeric characters would probably be fooled. Trying to detect the scheme used to generate the password could be helpful in choosing a relevant heuristic for deciding the password strength. Ont the other hand, I would consider it very bad to actually test whether the URL is resolvable in any way that leaks information about the password to the outside. [[User:Pmakholm|Pmakholm]] ([[User talk:Pmakholm|talk]]) 11:11, 1 July 2016 (UTC)
 Currently the explanation says: "Finally, emoji will often include unicode characters, which means that, if one can effectively salt passwords with emoji, then the passwords should be able to be stored in unicode (although that *probably* doesn't require anything outside the Base Multilingual Plane, so that might not need full unicode support after-all)."  I'm fairly convinced that this doesn't make sense and is incorrect.  Regardless of what character encoding the password is in, hashing will convert the entire thing into binary.  This binary is then typically stored as a base64-encoded string in the database.  Ergo, it doesn't matter whether the original password strings were in unicode or not: they will be stored in the database as ascii (or binary), not unicode.  I'm going to go ahead and remove this comment from the explanation.  I'm pretty certain that there isn't enough information in the comic to figure out why salting passwords with emoji would fix a unicode-handling bug in the URL request library.  So I suspect that there is no explanation there: either Cueball is entirely confused and his statement makes no sense, or there is simply not enough information given to help us understand why this solution might fix the problem.  However, I'm not going to make any updates to the explanation about this yet, because perhaps I'm missing something someone else will notice. [[User:Cmancone|Cmancone]] 12:50, 29 June 2016 (ETC)

← Older revision		Revision as of 09:58, 4 July 2016
Line 35:		Line 35:
	The explanation of 'Resolveable URL' is very confusing and mostly wrong, it is mixing up technologies like HTTP and DNS and is confusing FQDN's with URLs. Though admittedly, the term 'resolveable URL' is a bit of a misnomer by itself. URLs are typically not resolved, they contain an FQDN that is resolved via DNS to an IP(v6) address and optionally port. The remainder of the URL can be used to identify a resource on that server, but how this is done and signaled is quite application/protocol dependent (and shouldn't be called 'resolving'). So if you hit a 404 the FQDN actually resolved but the HTTP resource could not be found. A non-resolveable URL would give a browser error like 'unknown host'. [[Special:Contributions/162.158.83.198\|162.158.83.198]] 09:59, 1 July 2016 (UTC)		The explanation of 'Resolveable URL' is very confusing and mostly wrong, it is mixing up technologies like HTTP and DNS and is confusing FQDN's with URLs. Though admittedly, the term 'resolveable URL' is a bit of a misnomer by itself. URLs are typically not resolved, they contain an FQDN that is resolved via DNS to an IP(v6) address and optionally port. The remainder of the URL can be used to identify a resource on that server, but how this is done and signaled is quite application/protocol dependent (and shouldn't be called 'resolving'). So if you hit a 404 the FQDN actually resolved but the HTTP resource could not be found. A non-resolveable URL would give a browser error like 'unknown host'. [[Special:Contributions/162.158.83.198\|162.158.83.198]] 09:59, 1 July 2016 (UTC)
	:Feel free to adjust the text as desired. I think in this case it is best to understand "Resolvable URL" as Cueball meant it, which (I think) is as any valid URL you might stick in your web browser. I don't think he meant any of the more technical possible definitions. In that sense a resolvable URL would be something that points to a server, potentially followed by a resource on the server. At least, that is how I would think to describe it. Feel free to give it a go. {{unsigned\|Cmancone}}		:Feel free to adjust the text as desired. I think in this case it is best to understand "Resolvable URL" as Cueball meant it, which (I think) is as any valid URL you might stick in your web browser. I don't think he meant any of the more technical possible definitions. In that sense a resolvable URL would be something that points to a server, potentially followed by a resource on the server. At least, that is how I would think to describe it. Feel free to give it a go. {{unsigned\|Cmancone}}
		+
		+	Around the time this comic was published, Firefox linked on its start-page to https://advocacy.mozilla.org/en-US/encrypt/codemoji/2, where a webapp Codeempji is available. With this webapp one can use emojis to scramble messages with a Caesar-cipher like method. This might be the reason for the emoji reference in the title text.[[Special:Contributions/162.158.85.147\|162.158.85.147]] 09:58, 4 July 2016 (UTC)

@@ Line 1: / Line 1: @@
-''Italic text''<!--Please sign your posts with ~~~~-->
+<!--Please sign your posts with ~~~~-->
 I'm new. For the explanation: A bug, as in a computer (programming) bug, can be reported and tracked, and many systems allow collaboration on the reporting and tracking of problems, or bugs, in code, and their solutions. Cueball reported a problem (bug) he found in the code, which presumably caused the server (program)&mdash;which he wrote as part of his project&mdash;to try to read the passwords as URLs before storing them. This exposes serious cross-site scripting attacks and other serious security vulnerabilities, and since handling password and user account information usually requires a lot of programming, this would be difficult to fix, which is why the character off-panel suggests burning the project down, as that would be much easier, and would solve any security problems, much more quickly than fixing the bug would. The comment text refers to Cueball's horrid solution to a horrid problem: Instead of solving the problem that is causing the server to read passwords as URLs, he can instead leverage a known problem in the programme which reads URLs which prevents it from reading a particular way of representing text in binary form, by adding a few characters to the user's password that the URL-reading program can't read. This would also "salt" the user's password, which is a security technique that makes passwords harder to figure out when they are stored properly. Cueball thinks this would solve the original problem, and two other problems at the same time, the second problem being the fact that user's passwords aren't salted (a security problem). The third solved problem is difficult to deduce.   &emsp;[[User:Zyzygy|Zyzygy]] 05:40, 29 June 2016 (UTC)
@@ Line 31: / Line 30: @@
 In the nomenclature I am familiar with mailto:somebody@example.com is a URL.  If you accept that mailto (and other protocols) are also URLs some of the description is untrue.  Fortunately the untrue bits are also unnecessary and can be deleted or generalized.--[[Special:Contributions/108.162.219.11|108.162.219.11]] 04:51, 1 July 2016 (UTC)
 Definitely a sequel to 1084[[Special:Contributions/108.162.221.92|108.162.221.92]] 08:27, 1 July 2016 (UTC)
 The explanation of 'Resolveable URL' is very confusing and mostly wrong, it is mixing up technologies like HTTP and DNS and is confusing FQDN's with URLs. Though admittedly, the term 'resolveable URL' is a bit of a misnomer by itself. URLs are typically not resolved, they contain an FQDN that is resolved via DNS to an IP(v6) address and optionally port. The remainder of the URL can be used to identify a resource on that server, but how this is done and signaled is quite application/protocol dependent (and shouldn't be called 'resolving'). So if you hit a 404 the FQDN actually resolved but the HTTP resource could not be found. A non-resolveable URL would give a browser error like 'unknown host'. [[Special:Contributions/162.158.83.198|162.158.83.198]] 09:59, 1 July 2016 (UTC)
-:Feel free to adjust the text as desired.  I think in this case it is best to understand "Resolvable URL" as Cueball meant it, which (I think) is as any valid URL you might stick in your web browser.  I don't think he meant any of the more technical possible definitions.  In that sense a resolvable URL would be something that points to a server, potentially followed by a resource on the server.  At least, that is how I would think to describe it.  Feel free to give it a go.
+:Feel free to adjust the text as desired.  I think in this case it is best to understand "Resolvable URL" as Cueball meant it, which (I think) is as any valid URL you might stick in your web browser.  I don't think he meant any of the more technical possible definitions.  In that sense a resolvable URL would be something that points to a server, potentially followed by a resource on the server.  At least, that is how I would think to describe it.  Feel free to give it a go. {{unsigned|Cmancone}}

@@ Line 16: / Line 16: @@
 ::If you by 'server' means Apache it is not completely unexpected that a sloppy coded extension to Perl or PHP could crash part of the server – and I still maintain mod_perl code that does 'fancy' stuff. I wouldn't be surprised if Cueball still wrote web-application as he did when mod_perl was the hot stuff. Today it is a common setup to have a chain of servers. In the front nginx for SSL termination, maybe an application level firewall filtering out spooky requests,  then Varnish for caching and load-balancing and finally the application server running the actual web-application – all layers implementing the HTTP protocol. Which of these are 'the server'? At least it is often easy for the application developer to make the last server in the chain unresponsive (i.e. crashed). [[User:Pmakholm|Pmakholm]] ([[User talk:Pmakholm|talk]]) 12:08, 1 July 2016 (UTC)
-Regarding those last two points: sorry for my long unsigned rant.  Didn't realize I wasn't logged in.  Still haven't figured out how to sign comments.  Gonna try it this time. [[User:Cmancone|Cmancone]] ([[User talk:Cmancone|talk]]) 16:51, 29 June 2016 (UTC)--
+:::Writing an extension to your language of choice would probably be a good way of crashing the server, although I would say that writing extensions to the language itself is not a common thing for most people to do.  I suppose I'm arguing from experience (which is not always accurate) but in years of PHP and python programming I've never once had to write a language extension, nor did I ever need to for my very complicated thesis work.  So I would say that the general point still stands: if Cueball is crashing any part of the server, he is doing things very wrong or at least very different.[[User:Cmancone|Cmancone]] ([[User talk:Cmancone|talk]]) 12:58, 1 July 2016 (UTC)
 :You made it ;-) --[[User:Kynde|Kynde]] ([[User talk:Kynde|talk]]) 20:22, 29 June 2016 (UTC)

← Older revision		Revision as of 12:43, 1 July 2016
Line 32:		Line 32:

	The explanation of 'Resolveable URL' is very confusing and mostly wrong, it is mixing up technologies like HTTP and DNS and is confusing FQDN's with URLs. Though admittedly, the term 'resolveable URL' is a bit of a misnomer by itself. URLs are typically not resolved, they contain an FQDN that is resolved via DNS to an IP(v6) address and optionally port. The remainder of the URL can be used to identify a resource on that server, but how this is done and signaled is quite application/protocol dependent (and shouldn't be called 'resolving'). So if you hit a 404 the FQDN actually resolved but the HTTP resource could not be found. A non-resolveable URL would give a browser error like 'unknown host'. [[Special:Contributions/162.158.83.198\|162.158.83.198]] 09:59, 1 July 2016 (UTC)		The explanation of 'Resolveable URL' is very confusing and mostly wrong, it is mixing up technologies like HTTP and DNS and is confusing FQDN's with URLs. Though admittedly, the term 'resolveable URL' is a bit of a misnomer by itself. URLs are typically not resolved, they contain an FQDN that is resolved via DNS to an IP(v6) address and optionally port. The remainder of the URL can be used to identify a resource on that server, but how this is done and signaled is quite application/protocol dependent (and shouldn't be called 'resolving'). So if you hit a 404 the FQDN actually resolved but the HTTP resource could not be found. A non-resolveable URL would give a browser error like 'unknown host'. [[Special:Contributions/162.158.83.198\|162.158.83.198]] 09:59, 1 July 2016 (UTC)
		+	:Feel free to adjust the text as desired. I think in this case it is best to understand "Resolvable URL" as Cueball meant it, which (I think) is as any valid URL you might stick in your web browser. I don't think he meant any of the more technical possible definitions. In that sense a resolvable URL would be something that points to a server, potentially followed by a resource on the server. At least, that is how I would think to describe it. Feel free to give it a go.