Editing Talk:1700: New Bug
Please sign your posts with ~~~~ |
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 1: | Line 1: | ||
<!--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)—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.  [[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.  [[User:Zyzygy|Zyzygy]] 05:40, 29 June 2016 (UTC) | ||
Line 13: | Line 14: | ||
:Finally, I think there is a big misunderstanding throughout this explanation. In a web services context the "server" (referenced in the comic) is a very different thing than the application that a programmer builds. A server can refer to either the computer itself or the software that is responsible for responding to web requests and executing the actual application. In a professional context, the application (which is what cueball would be building) would never be referred to as the "server". It is possible that this is a mis-use of terminology on the part of cueball or Randall, but I suspect that the term was used properly and intentionally. The reason is because if cueball's application is crashing the *server*, it takes the level of incompetence up to completely new (and unusual) levels, in much the same way that he has done in the past. Normally the programming language used to build the application, the software hosting the application, and the operating system itself have a number of safe guards in place to ensure that if an application misbehaves, the only thing that crashes is the application itself. For cueball's application to break through all those safeguards and crash the server itself (either the operating system or the web server software) would require cueball to have developed a program that operates *well* outside the bounds of normal procedures. Just for reference, as someone who has been building web software for over 15 years, I wouldn't even know where to start to crash the server from within an application. It would probably have to involve either exploiting a previously unknown bug in the programming language or some *very* poorly designed system calls. [[Special:Contributions/108.162.221.22 15:11, 29 June 2016 108.162.221.22]] (Rememeber to sign your comments) | :Finally, I think there is a big misunderstanding throughout this explanation. In a web services context the "server" (referenced in the comic) is a very different thing than the application that a programmer builds. A server can refer to either the computer itself or the software that is responsible for responding to web requests and executing the actual application. In a professional context, the application (which is what cueball would be building) would never be referred to as the "server". It is possible that this is a mis-use of terminology on the part of cueball or Randall, but I suspect that the term was used properly and intentionally. The reason is because if cueball's application is crashing the *server*, it takes the level of incompetence up to completely new (and unusual) levels, in much the same way that he has done in the past. Normally the programming language used to build the application, the software hosting the application, and the operating system itself have a number of safe guards in place to ensure that if an application misbehaves, the only thing that crashes is the application itself. For cueball's application to break through all those safeguards and crash the server itself (either the operating system or the web server software) would require cueball to have developed a program that operates *well* outside the bounds of normal procedures. Just for reference, as someone who has been building web software for over 15 years, I wouldn't even know where to start to crash the server from within an application. It would probably have to involve either exploiting a previously unknown bug in the programming language or some *very* poorly designed system calls. [[Special:Contributions/108.162.221.22 15:11, 29 June 2016 108.162.221.22]] (Rememeber to sign your comments) | ||
− | + | 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)-- | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | 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) | ||
:You made it ;-) --[[User:Kynde|Kynde]] ([[User talk:Kynde|talk]]) 20:22, 29 June 2016 (UTC) | :You made it ;-) --[[User:Kynde|Kynde]] ([[User talk:Kynde|talk]]) 20:22, 29 June 2016 (UTC) | ||
Explanation says "There is no reason for password handling code to access urls" but that is somewhat wrong -- Password handling code frequently perform heuristics on the password to assess the strength, for example checking if part of the password is a dictionary word -- similar heuristics could be done to check thatthe password is not a URL, such as "xkcd.com" applying DNS and other internet resources as an extention of the concept of "dictionary". [[User:Spongebog|Spongebob]] ([[User talk:Spongebog|talk]]) 16:11, 29 June 2016 (UTC) | Explanation says "There is no reason for password handling code to access urls" but that is somewhat wrong -- Password handling code frequently perform heuristics on the password to assess the strength, for example checking if part of the password is a dictionary word -- similar heuristics could be done to check thatthe password is not a URL, such as "xkcd.com" applying DNS and other internet resources as an extention of the concept of "dictionary". [[User:Spongebog|Spongebob]] ([[User talk:Spongebog|talk]]) 16:11, 29 June 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) | 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) | ||
Line 35: | Line 25: | ||
In the nomenclature I am familiar with mailto:[email protected] 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) | In the nomenclature I am familiar with mailto:[email protected] 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) | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− |