I work with my touch-pad as opposed to my mouse when programming as well. I'd rather not get into a vim argument, but as a vim user for many years, I can assure you that it simply increases productivity when used as a text editor.
The problem with mouse or touchpad is not that it's out of reach, but that it usually forces you to take your index fingers away from the "f" and "j" keys, plus it wastes time by making you point the cursor at the right place, which should most of the time be unnecessary when programming, as most of the operations you perform with mouse are not "location-specific" (with the exception of placing the cursor in the right place). However, I do agree that touch-pad has its advantages over the mouse, because I can usually point and click with my right thumb, without having to move my index fingers at all.
It is indeed a shame that such a great editor cannot be easily turned into an IDE.
My experience with plugins is exactly the same: they are slow, buggy, incomplete and very often interfere with one another.
A gvim fork which would combine the greatness of the editor with IDE features would be a dream. Imagine how nice it would be to have key bindings for every menu and every option. For instance, \p could open the "project" menu. All the menus and submenus would have a key combination associated with them. For instance, "New project" would be in the "project" menu and would be accessed by typing \pn (p as in project menu, n as in new).
IDEs increase productivity a lot with their features, vim increases productivity a lot by not having to touch your mouse every 3 seconds. Combining the two would be incredible imo.
As I said, HTTPS cannot be deployed everywhere because it is expensive: you have to buy certificates and extra computational power.
"Any form of authentication over plain-text is useless" There was not a single mention of authentication over plain-text in my post. Read about EKE (Encrypted Key Exchange) and client-side certificates.
"What exactly is wrong with HTTP Basic over SSL?" Nothing. I was specifically discussing authentication when HTTPS is not available. Do not forget that HTTP is still the default protocol in your address bar, so going to www.google.com will not access it via HTTPS, but HTTP. Google is nice enough to redirect you to its HTTPS version, but Eve can easily prevent that redirect. Technically illiterate Joe cannot be expected to manually prefix with "https://" or use an addon such as "HTTPS everywhere".
It is clear to me that you have missed the whole point of my post. I was discussing the necessity of addressing some security concerns in HTTP2.0 related to authentication. I have pointed out that there are good ways of doing so and you have not provided a single counter-argument to my claim.
Why won't they focus on what really matters? HTTP is still missing sane authentication techniques. Almost all websites require users to log in, so it should be a priority that a log in mechanism be supported in HTTP as opposed to being the responsibility of every web developer individually (don't you dare mention HTTP Basic Authentication). Relying on cookies alone to provide authentication is a joke. Not all websites afford to buy certificates or the performance penalty of HTTPS and security over HTTP is practically non-existent.
The HTTP protocol is very primitive and it has not evolved on par with the evolution of cryptography and security. A lot better privacy, confidentiality, authentication can be obtained with very little cost. Because most websites allow you to log in, the server and the client share a common piece of information that a third party does not, namely the client's password (or some digest of that). Because of this shared information, it should be far easier to provide security over HTTP (at least for existing users). I find it laughable that we still rely on a piece of fixed string sent as plain-text (the session cookie) to identify ourselves. Far better mechanisms exist (besides the expensive HTTPS) to guarantee some security, and it should not be the responsibility of the web developer to implement these mechanisms.
At the very least, HTTP 2.0 should support password-authenticated key agreement and client authentication using certificates.
While signing up can still be problematic in terms of security, logging in need not be. There's a huge difference between being exposed once and being exposed every time. If there was no Eve to monitor your registration on the website, then there should be no Eve that can harm you any longer. You have already managed to share some secret information with the server, there is no reason to expose yourself every time you log in by sending your password in plain text and then sending a session in plaintext every time you make a request. That is, a session which can be used by anyone.
While it may be acceptable for HTTP1.1 to not address such security concerns, I would find it disturbing for HTTP2.0 not to address them either. To get an intuitive idea on how easy it can be to have "safer proofs" that you are indeed logged in, consider the following scenario: you have registered to the website without an attacker interfering; you would like to log-in, so you perform an EKE with the server and you now have a shared secret; every time you send a request to that website, you send some cookie _authenticated = sha2(shared_key || incremental_request_number). Obviously, even if Eve sees that cookie, it cannot authenticate itself in the next request, because it does not know the shared_key and thus cannot compute the "next hash". This is just an example proof-of-concept technique to get an idea on how much better we can do. Many other cheap techniques can be employed. This one has the overhead of only one hash computation.
Given that HTTP is a tremendously used protocol, it does make sense to make it as space-efficient as possible, being responsible for a large portion of the bandwidth. I do believe it matters on a large scale. However, given the arguments above, this should not be their priority.
On second thought, the idea above is merely a zero-knowledge proof which can be easily achieved with homomorphic encryption. I think this could be achieved with javascript so website developers can easily integrate a more secure login with almost zero overhead server-side, and unnoticeable overhead client-side.
Using HMAC SHA-1 over HMAC MD5 is no more convincing than using AES-192 over AES-128. For regular security needs, AES-128 is considered sufficient. For greater needs, there's AES-192 and AES-256. The same logic applies for HMAC-MD5,HMAC-SHA1 and HMAC-512.
If I remember correctly, PHP's main developer broke the crypt() function and their regression testing was so poor that the bug went into a stable release. Not to mention that everyone was like "everyone can misunderstand the manpage for strcpy!". I wouldn't put too much faith in anything good coming out of PHP.
Firstly, a bad tool becoming so popular to the point where it's nearly impossible to convince people not to use it is not an uncommon effect.
Just like w3schools is so widely spread although one of the poorest sources of documentation for html and the like,
MD5 is still pretty much the first thing most programmers are taught by others when it comes to storing passwords (especially PHP programmers, who often have no clue what they are doing, as they're pretty much the only people not using prepared statements in 2012).
Secondly, it often appears to be in human's nature to simply not care about consequences when they seem so unlikely to occur to one. Just like you know your door lock can be broken easily and there are better alternatives yet you are not switching, many programmers simply come to the conclusion that whether they choose MD5 or something else, it will likely not matter at all. "Who's going to manage to break into my database and steal my hashes in the first place, anyway". Unsalted MD5 is still a trend among PHP programmers (just like mysql). Besides, a reasonably strong password with a salt is still not very "easy" to break, and pragmatic programmers simply don't care that you can generate collision pairs efficiently.
It would be interesting to try to create some cryptosystem providing:
- a Hash(Key, Password) function;
- a Compare(Key1, Key2, Hash1, Hash2) which returns true only when
Password1=Password2 in Hash(Key1, Password1)=Hash(Key2, Password2).
When a user registers an account:
- Server gives the client a randomly generated challenge Key1;
- Client provides H = Hash(Key1, Password) to the server;
- Server stores Key1 and H.
When a user logs in:
- Server gives the client a randomly generated challenge Key2;
- Client provides h' = Hash(Key2, Password);
- Server computes Compare(Key1, Key2, h, h').
I'm not sure creating such a cryptosystem is possible, I have not given it much thought.
It would be nice if Hash were expensive to compute but Compare were cheap. This has the added bonus
that the server will never know your password.
Even if one configures their wireless router to use the latest, most recommended
security protocols, their security is still not proven. Guaranteeing that a cryptosystem
is secure (for almost any sane formal definition of the word secure you may pick) is probably not a decidable problem,
or is very far from our reach.
The problem becomes tremendously more difficult if you also consider
possible implementation flaws (hardware and software).
In such a context, couldn't one simply claim that
"just because there's no publicly-known weakness in WPA2 or its implementation, this does not imply
that no-one in the world is aware of such a weakness and is capable of exploiting it".
At this point, I assume some slashdotter with come up with analogy to the above like the following:
"just because my house has a lock with no known flaws and some-one has been murdered in my living-room,
it doesn't mean it was not me. It could simply have been someone who knows to break my so-called perfect lock,
bringing a corpse into my house and then leaving."
He has not claimed that you have to be a fast typist in order to be a good programmer, but merely that a good programmer can almost always type quickly. According to the common "programming is to be learned in 10 years" saying, it is highly unusual to become experienced in programming without unwillingly getting a high WPM score in the meantime.
It is understandable why one would not put much faith in a programmer that cannot type quickly, not because typing quickly is a requirement for being a good programmer, but because it inevitably comes with being a good programmer. The same thing happens with a pianist, with the exception that it is more important for pianists to be fast than it is for computer programmers.
Slashdot Mirror
also wonder what the waves in the visible spectrum look like.
I work with my touch-pad as opposed to my mouse when programming as well. I'd rather not get into a vim argument, but as a vim user for many years, I can assure you that it simply increases productivity when used as a text editor.
The problem with mouse or touchpad is not that it's out of reach, but that it usually forces you to take your index fingers away from the "f" and "j" keys, plus it wastes time by making you point the cursor at the right place, which should most of the time be unnecessary when programming, as most of the operations you perform with mouse are not "location-specific" (with the exception of placing the cursor in the right place). However, I do agree that touch-pad has its advantages over the mouse, because I can usually point and click with my right thumb, without having to move my index fingers at all.
It is indeed a shame that such a great editor cannot be easily turned into an IDE.
My experience with plugins is exactly the same: they are slow, buggy, incomplete
and very often interfere with one another.
A gvim fork which would combine the greatness of the editor with IDE features
would be a dream. Imagine how nice it would be to have key bindings for every
menu and every option. For instance, \p could open the "project" menu. All the
menus and submenus would have a key combination associated with them.
For instance, "New project" would be in the "project" menu and would be accessed
by typing \pn (p as in project menu, n as in new).
IDEs increase productivity a lot with their features, vim increases productivity a lot
by not having to touch your mouse every 3 seconds. Combining the two would be
incredible imo.
As I said, HTTPS cannot be deployed everywhere because it is expensive: you have to buy certificates and extra computational power.
"Any form of authentication over plain-text is useless"
There was not a single mention of authentication over plain-text in my post. Read about EKE (Encrypted Key Exchange) and client-side certificates.
"What exactly is wrong with HTTP Basic over SSL?"
Nothing. I was specifically discussing authentication when HTTPS is not available. Do not forget that HTTP is still the default protocol in your address bar, so going to www.google.com will not access it via HTTPS, but HTTP. Google is nice enough to redirect you to its HTTPS version, but Eve can easily prevent that redirect. Technically illiterate Joe cannot be expected to manually prefix with "https://" or use an addon such as "HTTPS everywhere".
It is clear to me that you have missed the whole point of my post. I was discussing the necessity of addressing some security concerns in HTTP2.0 related to authentication. I have pointed out that there are good ways of doing so and you have not provided a single counter-argument to my claim.
Why won't they focus on what really matters? HTTP is still missing sane authentication techniques. Almost all websites require users to log in, so it should be a priority that a log in mechanism be supported in HTTP as opposed to being the responsibility of every web developer individually (don't you dare mention HTTP Basic Authentication). Relying on cookies alone to provide authentication is a joke. Not all websites afford to buy certificates or the performance penalty of HTTPS and security over HTTP is practically non-existent.
The HTTP protocol is very primitive and it has not evolved on par with the evolution of cryptography and security. A lot better privacy, confidentiality, authentication can be obtained with very little cost. Because most websites allow you to log in, the server and the client share a common piece of information that a third party does not, namely the client's password (or some digest of that). Because of this shared information, it should be far easier to provide security over HTTP (at least for existing users). I find it laughable that we still rely on a piece of fixed string sent as plain-text (the session cookie) to identify ourselves. Far better mechanisms exist (besides the expensive HTTPS) to guarantee some security, and it should not be the responsibility of the web developer to implement these mechanisms.
At the very least, HTTP 2.0 should support password-authenticated key agreement and client authentication using certificates.
While signing up can still be problematic in terms of security, logging in need not be. There's a huge difference between being exposed once and being exposed every time. If there was no Eve to monitor your registration on the website, then there should be no Eve that can harm you any longer. You have already managed to share some secret information with the server, there is no reason to expose yourself every time you log in by sending your password in plain text and then sending a session in plaintext every time you make a request. That is, a session which can be used by anyone.
While it may be acceptable for HTTP1.1 to not address such security concerns, I would find it disturbing for HTTP2.0 not to address them either.
To get an intuitive idea on how easy it can be to have "safer proofs" that you are indeed logged in, consider the following scenario: you have registered to the website without an attacker interfering; you would like to log-in, so you perform an EKE with the server and you now have a shared secret; every time you send a request to that website, you send some cookie _authenticated = sha2(shared_key || incremental_request_number). Obviously, even if Eve sees that cookie, it cannot authenticate itself in the next request, because it does not know the shared_key and thus cannot compute the "next hash".
This is just an example proof-of-concept technique to get an idea on how much better we can do. Many other cheap techniques can be employed. This one has the overhead of only one hash computation.
Given that HTTP is a tremendously used protocol, it does make sense to make it as space-efficient as possible, being responsible for a large portion of the bandwidth. I do believe it matters on a large scale. However, given the arguments above, this should not be their priority.
I remember trying most of the relevant stuff on that page on archlinux and still not getting the sound to work properly.
Who would've thought a day would come when W3-schools is used as a reference in a non-humorous way?
You are disconsidering locally-required passwords (encrypting a file or partition, protecting a private key, authenticating into the OS etc.)
You don't seem to like the const keyword very much, do you?
550 lines of C++ code and nearly no appearances of const.
On second thought, the idea above is merely a zero-knowledge proof which can be easily achieved with homomorphic encryption. I think this could be achieved with javascript so website developers can easily integrate a more secure login with almost zero overhead server-side, and unnoticeable overhead client-side.
Using HMAC SHA-1 over HMAC MD5 is no more convincing than using AES-192 over AES-128. For regular security needs, AES-128 is considered sufficient. For greater needs, there's AES-192 and AES-256. The same logic applies for HMAC-MD5,HMAC-SHA1 and HMAC-512.
If I remember correctly, PHP's main developer broke the crypt() function and their regression testing was so poor that the bug went into a stable release. Not to mention that everyone was like "everyone can misunderstand the manpage for strcpy!". I wouldn't put too much faith in anything good coming out of PHP.
That method is nothing like I described and I doubt anyone serious about security is using it.
Also, I'm not sure HMAC MD5 is considered weak at all.
Firstly, a bad tool becoming so popular to the point where it's nearly impossible to convince people not to use it is not an uncommon effect. Just like w3schools is so widely spread although one of the poorest sources of documentation for html and the like, MD5 is still pretty much the first thing most programmers are taught by others when it comes to storing passwords (especially PHP programmers, who often have no clue what they are doing, as they're pretty much the only people not using prepared statements in 2012). Secondly, it often appears to be in human's nature to simply not care about consequences when they seem so unlikely to occur to one. Just like you know your door lock can be broken easily and there are better alternatives yet you are not switching, many programmers simply come to the conclusion that whether they choose MD5 or something else, it will likely not matter at all. "Who's going to manage to break into my database and steal my hashes in the first place, anyway". Unsalted MD5 is still a trend among PHP programmers (just like mysql). Besides, a reasonably strong password with a salt is still not very "easy" to break, and pragmatic programmers simply don't care that you can generate collision pairs efficiently.
It would be interesting to try to create some cryptosystem providing: - a Hash(Key, Password) function; - a Compare(Key1, Key2, Hash1, Hash2) which returns true only when Password1=Password2 in Hash(Key1, Password1)=Hash(Key2, Password2). When a user registers an account: - Server gives the client a randomly generated challenge Key1; - Client provides H = Hash(Key1, Password) to the server; - Server stores Key1 and H. When a user logs in: - Server gives the client a randomly generated challenge Key2; - Client provides h' = Hash(Key2, Password); - Server computes Compare(Key1, Key2, h, h'). I'm not sure creating such a cryptosystem is possible, I have not given it much thought. It would be nice if Hash were expensive to compute but Compare were cheap. This has the added bonus that the server will never know your password.
Dogs are more cute.
Even if one configures their wireless router to use the latest, most recommended security protocols, their security is still not proven. Guaranteeing that a cryptosystem is secure (for almost any sane formal definition of the word secure you may pick) is probably not a decidable problem, or is very far from our reach. The problem becomes tremendously more difficult if you also consider possible implementation flaws (hardware and software). In such a context, couldn't one simply claim that "just because there's no publicly-known weakness in WPA2 or its implementation, this does not imply that no-one in the world is aware of such a weakness and is capable of exploiting it". At this point, I assume some slashdotter with come up with analogy to the above like the following: "just because my house has a lock with no known flaws and some-one has been murdered in my living-room, it doesn't mean it was not me. It could simply have been someone who knows to break my so-called perfect lock, bringing a corpse into my house and then leaving."
"All PHP users should note that the PHP 5.2 series is NOT supported anymore. All users are strongly encouraged to upgrade to PHP 5.3.7."
I wonder what happens when sending multiple Host headers
is successful.
Seeing multiple people sleeping in lectures (especially when there's more of them right next to each other) always cracks me up.
Not all teachers provide proper course materials unfortunately.
You shouldn't be able to see her legs unless you're standing like right next to her though.
He has not claimed that you have to be a fast typist in order to be a good programmer, but merely that a good programmer can almost always type quickly. According to the common "programming is to be learned in 10 years" saying, it is highly unusual to become experienced in programming without unwillingly getting a high WPM score in the meantime. It is understandable why one would not put much faith in a programmer that cannot type quickly, not because typing quickly is a requirement for being a good programmer, but because it inevitably comes with being a good programmer. The same thing happens with a pianist, with the exception that it is more important for pianists to be fast than it is for computer programmers.