The production prototype is for testing the manufacturing process, not the product itself. The product itself has passed the prototype stage. Maybe you do need to rehash your definitions.
I can understand people do not use databases, because most people will not comprehand them right from the start. There is no feeling with what a database does. There is with a spreadsheet.
True. But another important matter is that you can start typing away in a spreadsheet without spending a second on thinking about your design. Before you can do something serious in Access you will have to at least think about which fields you are going to define.
Only after people have come to the conclusion that Excel lacks good multi-user and data consistency features, they realise that a more mature solution is required. Fortunately, by this time the users have a reasonably good idea of what this new solution should do.
However, if the Department of Homeland Security suspected that you were hiding data within your own obscure files, they could search the files themselves for "extra" data. They can prove such a message exists, even if they can't discover what the message is.
This is true, but finding well-encrypted data is much harder than finding plaintext data. Plaintext data has certain statistical properties, i.e. in ordinary English ascii-text some characters are used more often than others. Cipher text usually resembles a random stream of data. This means that a discovered "disturbance" in image data produced by information encoded in the low order bits might just as well have been produced by inaccuracies in a scanner or digital camera. I am not claiming it is impossible to show that data is hidden in an image, but I assume it will be much harder to prove this in court if the data is encoded using a "statistically sound" encryption algorithm.
For any system that takes password inputs from users i.e. the password is entered from outside the system, It really doesn't need to store the password even in encrypted format.
If I recall correctly, the password isn't stored in encoded form at all. A string of zeros is encoded using your supplied password as the key. The result is then stored in the passwd file. (See man crypt)
The system merely stores a hash value of the password , when the user enters the password, the sytem generates the hash of the user entered password and compares it with stored hash value.
You are overlooking the fact that identical passwords would produce identical hash values every time. This would make spotting identical passwords a breeze. Idem for creating dictionaries.
Would this technology really be of any use in urban areas? If I recall correctly, RADAR requires direct line-of-sight with respect to the to-be-tracked object. I would asume that seperating the transmitters from the receivers will only make this problem worse.
Slashdot Mirror
Probably available in source... just not built yet.
The production prototype is for testing the manufacturing process, not the product itself. The product itself has passed the prototype stage. Maybe you do need to rehash your definitions.
Compare this article with http://it.slashdot.org/article.pl?sid=04/04/13/145 2255&tid=126&tid=106
True. But another important matter is that you can start typing away in a spreadsheet without spending a second on thinking about your design. Before you can do something serious in Access you will have to at least think about which fields you are going to define.
Only after people have come to the conclusion that Excel lacks good multi-user and data consistency features, they realise that a more mature solution is required. Fortunately, by this time the users have a reasonably good idea of what this new solution should do.
However, if the Department of Homeland Security suspected that you were hiding data within your own obscure files, they could search the files themselves for "extra" data. They can prove such a message exists, even if they can't discover what the message is.
This is true, but finding well-encrypted data is much harder than finding plaintext data. Plaintext data has certain statistical properties, i.e. in ordinary English ascii-text some characters are used more often than others. Cipher text usually resembles a random stream of data. This means that a discovered "disturbance" in image data produced by information encoded in the low order bits might just as well have been produced by inaccuracies in a scanner or digital camera. I am not claiming it is impossible to show that data is hidden in an image, but I assume it will be much harder to prove this in court if the data is encoded using a "statistically sound" encryption algorithm.
Exactly my point. This is why just storing the hashes (without a salt) doesn't cut the cake.
For any system that takes password inputs from users i.e. the password is entered from outside the system, It really doesn't need to store the password even in encrypted format.
If I recall correctly, the password isn't stored in encoded form at all. A string of zeros is encoded using your supplied password as the key. The result is then stored in the passwd file. (See man crypt)
The system merely stores a hash value of the password , when the user enters the password, the sytem generates the hash of the user entered password and compares it with stored hash value.
You are overlooking the fact that identical passwords would produce identical hash values every time. This would make spotting identical passwords a breeze. Idem for creating dictionaries.
Would this technology really be of any use in urban areas? If I recall correctly, RADAR requires direct line-of-sight with respect to the to-be-tracked object. I would asume that seperating the transmitters from the receivers will only make this problem worse.