I've have started using NoScript since recently, and remove those cheesy Skybuttons that came with kopete, and it's amazing how responsive Firefox has now become:-)
cameras to read license plate numbers of cars lacking the cards.
Will people with non-US cars (Mexican, Canadian) get to cross the bridge for free? And what about rental cars?
Why not have a number of dedicated FasTrak toll lanes, and a couple of lanes with human toll collectors (like is done on French motorways, and probably elsewhere too). Moreover, this will allow for a gradual reduction of the toll collector's workforce, rather than having to fire everybody at once...
but I don't remember anything about it being case insensitive... Where did that come from?
Probably some windows-head throwing in an extra toupper() before passing on the password to crypt().
Problem is, even after fixing this for new passwords, they can't change it for old passwords, or they'll lock out old accounts for which they don't have the original capitalization...
It's not always limited budgets which are the problem. Sometimes, excessive budgets create bigger problems, such as the urge of some members of management to dip into them.... So, they ditch all the volunteers who did sysadmin before, and instead hire a company to manage the systems for an overinflated price and handsome kickbacks. With the predictable results that the former sysadmin volunteers are not too happy.
A highschool here though it to be smart to run their school servers on Windows. Of course, the high-school's director had the admin password.
While being away (... attending a seminar about Windows security, ironically enough...), he got a mail from the admin guy (Some.Name@yahoo.it) claiming that a crash had happened, he had mislaid/forgotten his password, could the director mail him his.... which he did.
Only trouble was, it was not the admin guy having sent that mail, but a student who had just created an account on yahoo.it with a suitably sounding user name... and apparently Outlook (which the director uses...) only displays the user name, but not the domain. Instant fail.
The student then proceeded to send a prank letter very critical of the school to all users in the school's address book (parents, teachers, students...)
This has as much to do with the Antikythera mechanism as a software simulation. The mechanism has no differential gears, which are used on this lego construct because its creator played with them during his experiments with Babbage's Difference Engine.
Nope, the main reason for using differential gears is that with normal Lego gear pieces only certain ratios are achievable... which unfortunately do not include those needed by the Antikythera mechanism. So they had to obtain those by averaging two obtainable rations. And, in order to perform this "averaging" you need differential gears.
So this is a mechanism achieving the same purpose as Antikythera, but implemented using a completely different way due to different constraints.
.... which also shows that it is not a replica of the Antikhera mechanism. It achieves the same purpose (predicting eclipses), but using a different mechanism, because they needed to work with gear ratios achievable with available Lego pieces, and thus needed to add differentials, whereas the Greeks had no such needs (making their own gears, so being able to directly use whatever ratio was needed). Moreover, display differences (4-wind spirals versus 5) introduced more differences in the multiplicative constants, and thus the mechanism:
Because it would be difficult to fit the information for 223 lunar months in a single rotation of a dial, the original machine used a 5 wind spiral to encode the information. This made more space available for the markings required for the eclipse information.
My version of the machine uses a 4 wind spiral. This provides the same benefit as a 5 wind spiral but matches the Full Moon Cycle which may permit future enhancements to accuracy.
This change results in the formula:
Saros4 = Y * 4 * 235 / (223 * 19)
I decided to not use the Corinthian calendar and instead use the standard Gregorian civil calendar in a four wind spiral representing the four year leap year cycle.
Noting that 235 is 5 * 47 and 254 is 2 * 127, the important constants for the construction are:
4, 5, 19, 47, 127, and 223.
The readily available high quality LEGO gear ratios are combinations of 1, 3, and 5. With some challenge 4 is available. With these combinations we can get to gear ratios which are multiplicative combinations of these values. The easy ratios we can get to include: 1, 3, 4, 5, 9, 12, 15, 20, 25, 27, etc.
Ratios of 19, 47, 127, and 223 are impossible to achieve with simple gear ratios because they are prime numbers. We have to look beyond simple gears to differentials.
I don't see any other alternative than only having https login pages.
Exactly. And the user should be required to enter that https himself, or else he will forget to check that it's there.
Note, when you go to facebook.com (i.e. www.facebook.com, i.e. http://www.facebook.com/ you are presented with a login page with user and password text entry. There is no redirection to an https login page involved.)
Sorry, my mistake, my language was a little bit sloppy. Facebook doesn't actually use a redirection to https, but instead just uses a https URL as the form action. Same reasoning still applies: as the form itself is served via http, it is trivial for an interloper to change that https in the form action into an interceptable http.
Other providers, such as yahoo, do use a redirection to https. This has the advantage that the observant user can see at a glance that the connection is not being tampered with (whereas with Facebook, the user would need to view source to make the same assessment)
The Joule-Thomson effect is for a situation where the expanding gas does no work (i.e. streaming through a throttling valve into a low-pressure region). If the gas does work (pushes a piston, spins a turbine) while expanding, it always cools on expansion, and heats on compression. Quoting from wikipedia:
If the expansion process is reversible, meaning that the gas is in thermodynamic equilibrium at all times, it is called an isentropic expansion. In this scenario, the gas does positive work during the expansion, and its temperature
decreases.
In a free expansion, on the other hand, the gas does no work and absorbs no heat, so the internal energy is conserved. Expanded in this manner, the temperature of an ideal gas would remain constant, but the temperature of a real gas may either increase or decrease, depending on the initial temperature and pressure.
So some websites (still?) send login and password info as cleartext?
Only niche web sites such as gayromeo.com . They do have an https option, but that's only for paying customers.
Most mainstream sites (such as facebook, yahoo, etc.) do transmit their passwords over https, but their entry page is http, which makes it trivially easy for an attacker to just change the form, and use http instead.
Why do we enable incompetent people to get rich?
Well, in gayromeo's case, not using https is not really "incompetence", but one way to get rich... One more argument for taking a paying subscription rather than using the free service.
Actually most of these sites' entry page are https... including banks.
Yes, facebook (and many other services) fortunately do transmit the actual login data over https, but in order to make sure that no man-in-the-middle has tampered with the form action URL, the user needs to do view source! How many people are going to do that?
Actually, the login data is transmitted via https (although the form itself is in an http page). Go to your page, and do a view source.
Around here, it has "<form method="POST" action="https://login.facebook.com/login.php?login_attempt..." in it. Do a view source yourself, search for login.facebook.com, and see for yourself!
If you do indeed see a non-https action URL, chances are that you are in a non-democratic country running a malicious proxy which changed it into http to spy on you... and that is the real danger of facebook's setup (and yahoo's, and many others'...).
Facebook went to the expense of using https for each login, but unfortunately then they bungled it in such a way that the user has to do a view source to make sure it hasn't been tampered with...
It *is* possible to encrypt the password for real before the password gets passed to the server, by means of using some javascript with a one-way encryption (think pgp) and a public key, but that would require disclosing the public key as well as the encryption algorithm being used, which isn't very good mojo.
That could still be subverted by a MITM. Actually Tunisia pulled off their hack by inserting extra javascript into Facebook's pages. If they can insert javascript, they can also remove javascript. So the encrypting javascript would be removed from the page, and the encryption run on their man-in-the-middle server instead. Neither browser, nor the server would be none the wiser.
With https, you have at least some subtle cues such as the lock icon, and the https in the URL, which allows the more observant users to spot that some monkey business is going on...
I'm sorry, obviously you have nevver heard of HTTPS. You are a moron, perhaps?
Welcome to the real world... where most people couldn't care less whether a connection is http or https. And where most web services have a "user friendly" entry page accessible via http (which then may, or may not redirect to https for login purposes). But as the entry point was http, a man in the middle can then just disable https from that point on, and insert his own http-to-https proxy. As most users are unfortunately morons, they won't notice the missing lock icon, and the missing s after http. And no noisy "bad certificate" warning either, as the connection between browser and man-in-the-middle is still http...
The world would be a safer place, if we had set up our secure sites such that user needed to enter the s after http explicitly, rather than pandering to the morons who can't be bothered. By "helpfully" redirecting http to https, we have educated a generation of users that they don't need to care about those finer points...
That's why FB's response was to respond to all requests from Tunisia using https.
That would still leave those users out in the cold that don't know that they're now supposed to enter https://www.facebook.com/ . Unfortunately, that would be 99% of the users...
but my guess is simply the issue of- facebook _allows_ http logins
No, the main problem is that facebook expects the user to enter a http URL, and then redirects to https. All a malicious man in the middle man has to do, is disable this redirection.
Having no plain http login won't help, because the middle man can always present a http login page to the user, and translate the user's response to https and forward it to the server. The browser won't notice any mismatched certificate, as the connection at that end is still http. And the server doesn't check for certificates (unless client certificates are used, but that would be really cumbersome for a free service such as facebook...)
Slashdot Mirror
Any of a number of calendars from civilizations that didn't make it to the 20th century.
The Mayan calendar is still in use by the US army (who will go on Defcon 3 on 2012-12-21)
Ah, feels better now.
I've have started using NoScript since recently, and remove those cheesy Skybuttons that came with kopete, and it's amazing how responsive Firefox has now become :-)
Not in Dallas. The cars are charged based on license plate number and they just add tolls to your rental cost.
What if the car rental company only gets the bill a couple of days after you've brought back the car and left back to your home country...?
Or do it like the Swiss, have a yearly pass.
cameras to read license plate numbers of cars lacking the cards.
Will people with non-US cars (Mexican, Canadian) get to cross the bridge for free? And what about rental cars?
Why not have a number of dedicated FasTrak toll lanes, and a couple of lanes with human toll collectors (like is done on French motorways, and probably elsewhere too). Moreover, this will allow for a gradual reduction of the toll collector's workforce, rather than having to fire everybody at once...
You store both the strong hash and the weak crypt() hash side by side; and on the second login you replace the old crypt() hash.
But only if second login matches, obviously. Pretty smart.
Alternatively... you prompt them to enter a new password twice on the first login (which can be the same or different from the old one).
Would needlessly worry the users.
but I don't remember anything about it being case insensitive... Where did that come from?
Probably some windows-head throwing in an extra toupper() before passing on the password to crypt().
Problem is, even after fixing this for new passwords, they can't change it for old passwords, or they'll lock out old accounts for which they don't have the original capitalization...
limited non-profit budgets
It's not always limited budgets which are the problem. Sometimes, excessive budgets create bigger problems, such as the urge of some members of management to dip into them.... So, they ditch all the volunteers who did sysadmin before, and instead hire a company to manage the systems for an overinflated price and handsome kickbacks. With the predictable results that the former sysadmin volunteers are not too happy.
While being away (... attending a seminar about Windows security, ironically enough...), he got a mail from the admin guy (Some.Name@yahoo.it) claiming that a crash had happened, he had mislaid/forgotten his password, could the director mail him his.... which he did.
Only trouble was, it was not the admin guy having sent that mail, but a student who had just created an account on yahoo.it with a suitably sounding user name... and apparently Outlook (which the director uses...) only displays the user name, but not the domain. Instant fail.
The student then proceeded to send a prank letter very critical of the school to all users in the school's address book (parents, teachers, students...)
This has as much to do with the Antikythera mechanism as a software simulation. The mechanism has no differential gears, which are used on this lego construct because its creator played with them during his experiments with Babbage's Difference Engine.
Nope, the main reason for using differential gears is that with normal Lego gear pieces only certain ratios are achievable... which unfortunately do not include those needed by the Antikythera mechanism. So they had to obtain those by averaging two obtainable rations. And, in order to perform this "averaging" you need differential gears.
So this is a mechanism achieving the same purpose as Antikythera, but implemented using a completely different way due to different constraints.
See Building complex machines using lego pieces, and then scroll to "The Practical Considerations" (hey, never heard of an <a name=""> tag?)
Because it would be difficult to fit the information for 223 lunar months in a single rotation of a dial, the original machine used a 5 wind spiral to encode the information. This made more space available for the markings required for the eclipse information.
My version of the machine uses a 4 wind spiral. This provides the same benefit as a 5 wind spiral but matches the Full Moon Cycle which may permit future enhancements to accuracy.
This change results in the formula:
Saros4 = Y * 4 * 235 / (223 * 19)
I decided to not use the Corinthian calendar and instead use the standard Gregorian civil calendar in a four wind spiral representing the four year leap year cycle.
Noting that 235 is 5 * 47 and 254 is 2 * 127, the important constants for the construction are:
4, 5, 19, 47, 127, and 223.
The readily available high quality LEGO gear ratios are combinations of 1, 3, and 5. With some challenge 4 is available. With these combinations we can get to gear ratios which are multiplicative combinations of these values. The easy ratios we can get to include: 1, 3, 4, 5, 9, 12, 15, 20, 25, 27, etc.
Ratios of 19, 47, 127, and 223 are impossible to achieve with simple gear ratios because they are prime numbers. We have to look beyond simple gears to differentials.
Spoons don't make whales fat, food does.
It's really sad that this is the best scapegoat they could drag out; but, because the majority of the population hasn't played the game, it'll fly.
You mean, goatse can fly? I though that was monkeys?
I don't see any other alternative than only having https login pages.
Exactly. And the user should be required to enter that https himself, or else he will forget to check that it's there.
Note, when you go to facebook.com (i.e. www.facebook.com, i.e. http://www.facebook.com/ you are presented with a login page with user and password text entry. There is no redirection to an https login page involved.)
Sorry, my mistake, my language was a little bit sloppy. Facebook doesn't actually use a redirection to https, but instead just uses a https URL as the form action. Same reasoning still applies: as the form itself is served via http, it is trivial for an interloper to change that https in the form action into an interceptable http.
Other providers, such as yahoo, do use a redirection to https. This has the advantage that the observant user can see at a glance that the connection is not being tampered with (whereas with Facebook, the user would need to view source to make the same assessment)
What people sometimes forget about is that such a cycle can be theoretically 100% efficient
In theory, all cycles are 100% efficient.
If the system is perfectly isolated and there is no friction, you get exactly the work you put in.
Yes, if. Actual physical systems however are not perfect, and there will always be some thermal leaks, and some friction.
How many people would actually check for an HTTPS connection before logging in to Facebook?
... especially since it takes a "view source" to do this check...
So some websites (still?) send login and password info as cleartext?
Only niche web sites such as gayromeo.com . They do have an https option, but that's only for paying customers.
Most mainstream sites (such as facebook, yahoo, etc.) do transmit their passwords over https, but their entry page is http, which makes it trivially easy for an attacker to just change the form, and use http instead.
Why do we enable incompetent people to get rich?
Well, in gayromeo's case, not using https is not really "incompetence", but one way to get rich... One more argument for taking a paying subscription rather than using the free service.
Really is annoying that Facebook defaults to http
Actually most of these sites' entry page are https... including banks.
Yes, facebook (and many other services) fortunately do transmit the actual login data over https, but in order to make sure that no man-in-the-middle has tampered with the form action URL, the user needs to do view source! How many people are going to do that?
Around here, it has "<form method="POST" action="https://login.facebook.com/login.php?login_attempt..." in it. Do a view source yourself, search for login.facebook.com, and see for yourself!
If you do indeed see a non-https action URL, chances are that you are in a non-democratic country running a malicious proxy which changed it into http to spy on you... and that is the real danger of facebook's setup (and yahoo's, and many others' ...).
Facebook went to the expense of using https for each login, but unfortunately then they bungled it in such a way that the user has to do a view source to make sure it hasn't been tampered with...
It *is* possible to encrypt the password for real before the password gets passed to the server, by means of using some javascript with a one-way encryption (think pgp) and a public key, but that would require disclosing the public key as well as the encryption algorithm being used, which isn't very good mojo.
That could still be subverted by a MITM. Actually Tunisia pulled off their hack by inserting extra javascript into Facebook's pages. If they can insert javascript, they can also remove javascript. So the encrypting javascript would be removed from the page, and the encryption run on their man-in-the-middle server instead. Neither browser, nor the server would be none the wiser.
With https, you have at least some subtle cues such as the lock icon, and the https in the URL, which allows the more observant users to spot that some monkey business is going on...
I'm sorry, obviously you have nevver heard of HTTPS. You are a moron, perhaps?
Welcome to the real world... where most people couldn't care less whether a connection is http or https. And where most web services have a "user friendly" entry page accessible via http (which then may, or may not redirect to https for login purposes). But as the entry point was http, a man in the middle can then just disable https from that point on, and insert his own http-to-https proxy. As most users are unfortunately morons, they won't notice the missing lock icon, and the missing s after http. And no noisy "bad certificate" warning either, as the connection between browser and man-in-the-middle is still http...
The world would be a safer place, if we had set up our secure sites such that user needed to enter the s after http explicitly, rather than pandering to the morons who can't be bothered. By "helpfully" redirecting http to https, we have educated a generation of users that they don't need to care about those finer points...
That's why FB's response was to respond to all requests from Tunisia using https.
That would still leave those users out in the cold that don't know that they're now supposed to enter https://www.facebook.com/ . Unfortunately, that would be 99% of the users...
but my guess is simply the issue of- facebook _allows_ http logins
No, the main problem is that facebook expects the user to enter a http URL, and then redirects to https. All a malicious man in the middle man has to do, is disable this redirection.
Having no plain http login won't help, because the middle man can always present a http login page to the user, and translate the user's response to https and forward it to the server. The browser won't notice any mismatched certificate, as the connection at that end is still http. And the server doesn't check for certificates (unless client certificates are used, but that would be really cumbersome for a free service such as facebook...)