You've founded multiple successful ventures related to technology. While many entrepreneurs may manage to pay their own bills working out of their garage, to "own their job", you've had success beyond that, more than once. What do you think is the biggest reason your projects have been much more successful than the typical entrepreneurial venture which never grows beyond just a few people?
Last time my old, gray-haired self was interested in switching jobs, companies were willing to pay 30% more than they had budgeted for the position in order to compete with my other offers.
If people don't want to hire you, the problem might not be your age.
If SQL had a 64-bit unsigned int, I'd use a pair of them. Alas, it doesn't. Postgres has an IP type which works, but my design has to work for SQL server. On the other hand, Microsoft SQL server does have decimal type, numeric. Hmmm..
On the third hand, the idiot before me decided to store 32-bit integers (ip addresses) as four seperate bytes, in four separate columns (in some tables). That's pretty silly. So when rewriting it to handle IPv6, my first step would be to bring some sanity to the situation by storing each single number in a single column. However if I don't fix it, I can change those four byte columns to four signed 64s (or decimals/numerics) . That would allow a pretty clean conversion, though it preserves the silliness using four columns to store a number.
You're right, though, the IP legitimately is two 64-bit numbers. Unsigned, though. Damn Microsoft.
You also use the opportunity to no longer need to work with the next ISP to have your addresses routed by using one-to-one NAT (not the far more commom port address translation, which is yucky). With one-to-one NAT, each machine still has a seperate IP, you can just map the network prefix from FF08:x to BEEF:x or whatever at the router. You can change ISPs instantly in an emergency.
>> And it takes ten times as long compared to using native 64-bit types. > Depending on operation it should take twice as many calls
Figure out how to manage that and I'll make us both billionaires. Maybe you'd care to demonstrate by showing us how you can two add 4-bit numbers using 2-bit operations.
Are you under the impression that border routers are the only thing that ever sees IP addresses?
64-bit CPUs *can* process 128-bit numbers, or anyway they can run code that emulates it. And it takes ten times as long compared to using native 64-bit types. Your mileage may vary, of course, but that's one benchmark on an Ivy Bridge - a 1000% performance penalty.
Actually try working with 128-bit numbers, IPv6, in common software like SQL Server. There IS no 128-bit unsigned number in SQL Server. You *can* jack around binary types, I have. It's a time-consuming pain in the ass. Speaking of databases, you may have noticed disks are WAY slower than CPUs, RAM, etc. So the bottleneck for performance on well-designed systems is how much data you have to read from disk. If the data is twice as big, you have to read twice as much, and you get half the performance (assuming you didn't add a stupidity bottleneck elsewhere).
64 addresses were provide enough for 2 billion addresses per person. That's already a ridiculously large number.
A compromise position would have ben to *define* IPv6 addresses as 128-bit, and only assign addresses starting with 64 zero bits, for the next couple hundred years or so. That way you'd only need to *process* the lower 64 bits for the next century or so. 200 years from now, we'll have 256-bit CPUs running on 256-bit busses, so it'll be easy to start processing the higher bits at that time, if we need to.
> Is the Microsoft SQL Server thing the only reason why you think 64-bit would have been better?
SQL server is one example that 64-bit software, on 64-bit computers, natively handles 64-bit numbers, while 128 bit requires gymnastics.
Generally, I think 64 bits would have been more than enough. It would have allowed us to assign 2 billion addresses to each person.:) Not that we'd actually do that, obviously. We would have done perhaps 256 addresses (8 bits) for most end users, while reserving 80%-90% of the address space for future addressing plans. As you said, we using only 190.0.0.0.0.0.0.0/8 (or even 0:0:0/16) would have been plenty for the next 40-200 years.
At the time, we were running into 2GB limits on RAM on Windows disk sizes, and I predicted that the 2TB limit on MBR partitions would be a problem soon. Getting rid of MBR and switching to GPT has in fact been painful. I wanted to go ridiculously big with IPs so we'd never run into a similar problem.
A compromise position would have been to define them as 128 bits, and reserve everything but 0/64 for later use - so all addresses in use would start with 64 zero bits. You'd only have to process the lowest 64 bits, even though the first 64 zeroes technically exist. Then, a hundred years from now, we could announce that we'd start assigning 001:/64 ten years later, so software would need to start paying attention to that additional bit. Of course we'd have 256-bit CPUs by then.
I don't see that buying a cert gets you anything at all, for authenticating or communicating with your own clients. Why would you trust Versign more than you trust yourself? That's all buying a cert gets you - it's signed by them rather than being signed by you.
Protect your root CA, perhaps by storing it offline, and of course with a passphrase. Ideally for maximum security while maintaining convenience, you can use your root CA only to generate an intermediate cert, then use the intermediate to sign client certs. That way you can have your root locked up in a safe deposit box, since you never use it except once every few years.
I suppose buying does mean you don't have to install your root on new machines when you get them.
Any way to obtain a cert, for my network only, to authenticate my hosts and clients... before going out on that damn internet?
That's called IEEE 802.1x. It's commonly used in corporate networks. You can set the router to allow no access until authenticated, or only allow them access to whatever resources are appropriate pre-auth.
There are enough/64 to give every person on earth 2,635,249,153 of them.
128 bits allows for HUGE numbers.
Long ago, when we were developing IPv6, I was part of the group who argued for 128 bit addresses rather than 64 bit. I've decided I was wrong. 64 bits would have been more than enough, and could be processed on 64-bit processors, in standard databases, without hassle. Since my side won the argument, we have 128-bit addresses, which are so big they are a pain in the ass in Microsoft SQL Server and elsewhere.
I absolutely understand why you'd say that. I've done that. However, the first thing the bad guys do when they want to break into a system is check for unpatched software. If you're running versions with known vulnerabilities, that makes things really easy for the bad guys.
So what can you do? For me, I use Linux and OS X. Yeah, if you're the type of person who enjoys fiddling with the registry, there's a learning curve. On the other hand, if you normally open browser when you sit down at your computer, Firefox, Chrome, and Opera are pretty much the same on any desktop OS.
>> I spent 15 years developing and writing password / pass phrase security tools used on a huge number of web sites. I analyzed millions
Fifteen years of forty hours a week (and sometimes sixty) analyzing passwords stored in plain text, cracking passwords, creating tools to reduce bad passwords, etc. That's 38,000 hours studying password use.
> Do you store the passwords as plain text ?
Once *I* show up, passwords normally end up as salted SHA2 before long. It was salted MD5 for a LONG time, and that's actually still secure given a sanity limit on length, such as 256 characters, but I recommend SHA2 now, using crypt(pass, '$5$
There are plenty of critisisms of Google which are reasonable. Sane people might point out how much they data-mine their users, for example.
> So it is because no one uses them and not to be anti competitive pricks?
So you think the idea is that people will ditch Windows and Mac, switching to ChromeOS in order to get Chrome Apps, which few people have ever heard of? On what planet does that make any sense?
> yet they will be supported for the foreseeable future on Chrome OS?? Does that mean chrome OS sucks balls so badly it can't survive without this legacy tech to lock users in
ChromeOS doesn't HAVE native apps. The browser is the OS usrland. With Chrome Apps, ChromeOS wouldn't have *any* apps. So yeah it makes sense to keep Chrome Apps on ChromeOS, at least until it gets support for Amdroid apps, and for a generous transition period afterward.
Does ChromeOS suck balls? For my computer use case, yes it does. For my wife, it's perfect. It's exactly what she wants for her laptop.
The article you linked to strongly supports the opposite conclusion: that four unrelated words is quite unlikely to be cracked .
First, it explains that most of the 15,000 passwords were 6-9 characters, so the cracker was able to break 7,000 of them in just a few minutes. It starts getting much harder (slower) after that. In mosts cases, 7,000 passwords is plenty for a single site. When a bad guy wants more passwords, typically they quickly crack 7,000 mlre easy ones from another site. They don't waste hours cracking the hardest ones.
For the article, they went ahead and "wasted" a few hours trying to get some more difficult ones. They even got some that were two words. As the Ars article explains:
---- Because these attacks are capable of generating a huge number of guessesâ"the square of the number of words in the dictâ"crackers often work with smaller word lists or simply terminate a run in progress once things start slowing down. ------
That's the SQUARE of the dictionary, two words, and Ars explains crackers generally don't spend the hours to do that. "Correct horse battery staple" is FOUR unrelated words. Time required is proportional to dictionary size to FOURTH POWER. Ars didn't do that, nobody does that. Ars didn't even attempt three words, much less four.
Seriously I've spent fifteen years doing password security full time. I've done careful analysis on far more attacks than you've ever heard of.
> properly encrypt/salt the database to protect against offline attacks
Strong hashes, properly salted, ARE important*. However protection from offline attacks requires BOTH a strong salted hash (~encryption) AND a strong password.
A good hash means that given the hash, you can't get the password BY REVERSING THE HASH. However, if you can GUESS the password, there's no need to reverse the hash; you just guessed the password correctly.
* On Linux, you can get a strong salted sha256 hash by using crypt() with a hash of the format "$5$random$'. Perl: crypt($password, '$5$' . $random . '$'): MySQL: ENCRYPT( ?, CONCAT('$5$', ?, '$') ), password, randomstring
Once I had a system where the power management (sleep) couldn't be turned off, and we wanted to use it for digital signage. So in about eight lines of code I turned an Arduino into a USB mouse and set it to wiggle the cursor every 5 minutes, thereby preventing the system from going to sleep.
Later, I wanted to wanted to guess someone's PIN number over night, so with a few lines of code I set the Arduino to act as a USB keyboard and type in every possible PIN, waiting a few seconds between tries.
Now, Microsoft is willing to pay me to wiggle a mouse around and occasionally click. Hmm...:)
Most of the celebrity hacks use exactly that vulnerability. How hard is it to find out what school Britney Spears went to, or what city she lived in?
I solution which still preserves the usefulness of the password reset questions is to answer them as if you were someone else. When it says "what high school did you go to?", pretend it says 'what high school did Chelsea Clinton go to?"
For example, if you wanted to password reset my account, you could easily find that that I went to a certain school. But that won't help, I fill in the information as if I were Colin Powell. Or maybe it's Abraham Lincoln. Or Justice Kennedy. Not knowing who I pretend to be, you can't determine how I'd answer those questions. On the other hand, if I ever forget my password, I can reset it by entering the name of Roger Waters' dog, rather than my own.
I spent 15 years developing and writing password / pass phrase security tools used on a huge number of web sites. I analyzed millions of brute force and dictionary attempts, as well as the offline tools.
In my professional opinion, where strength meters and password policies most often fail is that they greatly underestimate the importance of length. I recently encountered a site which required: 8-12 characters Must include upper and lower case Must include digits Must include punctuation
Well we've all been taught since 1st grade or so that punctuation goes at the end of a sentence, and the first letter is capitalized, so most passwords on the system are of the form: Capital lower lower lower lower lower lower digit punctuation.
Since the whole password is 8-12 characters, to get the digit and punctuation at the end you need a word that is 6-10 letters. Passwords are pretty predictable on that system. According to their policies, these are a good passwords: Password1! Passw0rd!
But this is a horrible password, that anybody can guess: YRNKBV JSYZCXPRM ZOXADEKO JARQYTLY OFOFBQ VKGDOSUE XFEUJQOHG TZBVHQIA WSBQHKVD SPIODPL
Allow and encourage long pass phrases. (Also encourage the term "pass phrase", not "password".) Making your pass phrase a tiny bit longer adds much more security than switching the number 0 for the letter O.
Ever heard of 2048 bit security? Or 1024 bit keys? That's how security professionals talk about strength - X number of bits. Those numbers refer to the LENGTH of the keys (passwords). That's what's most important above all.
> I'd be surprised if a kernel with a full driver stack would even fit by itself into 16 MB of flash
The full Redhat kernel and initrd is about 16MB - and contains drivers for most of the hardware Linux supports - RAID cards from 20 years ago, fibre channel, tons of network cards, etc. I'm pretty sure you won't be plugging a PCI-X RAID card into this $5 board, so why would you include those drivers in the boot image?
As someone else said, OpenWRT is pretty popular, and it's about 6MB.
Certainly the manufacturer's attorney would present the "we provide firmware at no charge" argument that you made. And plaintiff's attorney would say it doesn't matter because CFR says "It's guaranteed (but not really)" it's *deceptive*, which is unlawful regardless.
> it offends sound reason for something which is very clearly written to be "deceptive." Consider:
LIFETIME GUARANTEE!!!! (fix pages of fine print) Guarantee void if unapproved apps are installed. (more pages of fine print)
I would say that's deceptive. The clause voiding the warranty is written right there in the pages and pages of fine print - and it makes the "LIFETIME GUARANTEE!" claim deceptive because many users wouldn't actually have any guarantee under those terms. There may be no fundamental difference between "unapproved apps" and "unapproved firmware".
Quoting the Code of Federal Regulations: -- such provisions are deceptive under section 110 of the Act, 15 U.S.C. 2310, because a warrantor cannot, as a matter of law, avoid liability under a written warranty where a defect is unrelated to the use by a consumer of âoeunauthorizedâ articles or service. --
The phrase " warrantor cannot, as a matter of law, avoid liability... where a defect is unrelated to the use by a consumer of âoeunauthorizedâ articles or service" may apply.
The quoted CFR text is saying why a manufacturer may not void a warranty due to repair by unauthorized service centers, or using unauthorized parts. The text itself does *not* limit the "cannot, as a matter of law" to only unauthorized parts, though, and it could well be argued that "unauthorized firmware" is an "unauthorized part" which may not void a warranty.
> So, I'm an adult, I borrow your phone to make a phone call or for another purpose - guess what - you do NOT have the legal right to monitor my communications.
If you said "you do not have a MORAL right" you'd get no argument from me. However, since you specifcally said "legal right", I'll inform you that you're quite mistaken. Dozens of people have tried to make that argument in court and they've consistently failed. The owner of a device or network has an absolute LEGAL right to monitor the usage of their own network amd devices. Whether they have a MORAL right is of course a matter of opinion.
Suppose I install one of those "web safe" filter software packages on my own computer. You borrow my computer, and try to load midgetsfucking.com. The software I installed on my computer logs the communication between my computer and midgetsfucking.com. You sue me. You'll not only LOSE, you'll probably lose by summary judgement, without even getting a trial. Why? Because the LAW, in the US at least, is that we each have a complete right to monitor our own stuff.
You are of course welcome to write rambling 800 procedures if you choose to do so. You won't while working for *me*, but in your software, do what you want.
In the kernel, we use the 24x80 rule. Lines no longer than 80 characters, and functions, from kerneldoc to ending brace, should normally be less than 24 lines, shorter if they are more complex. That leaves 20 lines for the function body - if the function isn't particularly complex. Complex stuff needs to be shorter. That rule works for us. We're happy, our 85 million users are happy. If you have 85 million happy users, keep doing what you're doing.
I wouldn't know the full details of which RDMS supports what types of updates, but they've always worked for me, when it makes sense for them to work. (Ie, obviously you don't update a sum.)
But I haven't tried too many different updates of user-friendly views, because I generally design my systems where updates / insertions aren't normally done manually by ad-hoc queries. People can retrieve data with ad hoc queries if they choose, no harm in that. For inserts and updates, I want those controlled by the software anyway, with all the proper validation.
Since the inserts are done by software, there's no problem writing the software to use the base tables. In fact, if you have even a general concept of objects in mind when writing the software (not necessarily full OOP), tables which reflect your objects may be easier than human-friendly views anyway.
So anyway, yeah I haven't updated THAT many views, and I'm glad I haven't.
> if I have [any] evidence, can I be ordered by the court
Yes.
> if I have hidden evidence that ties me to a crime, can I be ordered by the court
Still yes, plus the concealing is an additional crime: Prosecution of Destroying or Concealing Evidence (Penal Code 135 PC)
A person knowing that any... thing, is about to be produced in evidence upon a trial, inquiry, or investigation, authorized by law, willfully destroys, erases, or CONCEALS the same...
(quoting California law as an example of law in a typical Western jurisdiction)
Normally, the person in possession or control of the evidence would be ordered to actually bring the evidence to the court. Where that's impractical, they'll be ordered to make it available to attorneys for both sides, in whatever manner makes sense given the type of evidence.
Here's a another explanation by someone who has been studying these matters since 1977. When an interviewer asked Hillary Clinton if she kept detailed records of what she did in Washington, Clinton replied "Heavens no! It could get subpoenaed! I donâ(TM)t write anything down."
Slashdot Mirror
You've founded multiple successful ventures related to technology. While many entrepreneurs may manage to pay their own bills working out of their garage, to "own their job", you've had success beyond that, more than once. What do you think is the biggest reason your projects have been much more successful than the typical entrepreneurial venture which never grows beyond just a few people?
Last time my old, gray-haired self was interested in switching jobs, companies were willing to pay 30% more than they had budgeted for the position in order to compete with my other offers.
If people don't want to hire you, the problem might not be your age.
You got me thinking. You're right,
If SQL had a 64-bit unsigned int, I'd use a pair of them. Alas, it doesn't. Postgres has an IP type which works, but my design has to work for SQL server. On the other hand, Microsoft SQL server does have decimal type, numeric. Hmmm ..
On the third hand, the idiot before me decided to store 32-bit integers (ip addresses) as four seperate bytes, in four separate columns (in some tables). That's pretty silly. So when rewriting it to handle IPv6, my first step would be to bring some sanity to the situation by storing each single number in a single column. However if I don't fix it, I can change those four byte columns to four signed 64s (or decimals/numerics) . That would allow a pretty clean conversion, though it preserves the silliness using four columns to store a number.
You're right, though, the IP legitimately is two 64-bit numbers. Unsigned, though. Damn Microsoft.
You can get an IPv6 assignment:
https://www.ripe.net/publicati...
You also use the opportunity to no longer need to work with the next ISP to have your addresses routed by using one-to-one NAT (not the far more commom port address translation, which is yucky). With one-to-one NAT, each machine still has a seperate IP, you can just map the network prefix from FF08:x to BEEF:x or whatever at the router. You can change ISPs instantly in an emergency.
>> And it takes ten times as long compared to using native 64-bit types.
> Depending on operation it should take twice as many calls
Figure out how to manage that and I'll make us both billionaires. Maybe you'd care to demonstrate by showing us how you can two add 4-bit numbers using 2-bit operations.
Are you under the impression that border routers are the only thing that ever sees IP addresses?
64-bit CPUs *can* process 128-bit numbers, or anyway they can run code that emulates it. And it takes ten times as long compared to using native 64-bit types. Your mileage may vary, of course, but that's one benchmark on an Ivy Bridge - a 1000% performance penalty.
Actually try working with 128-bit numbers, IPv6, in common software like SQL Server. There IS no 128-bit unsigned number in SQL Server. You *can* jack around binary types, I have. It's a time-consuming pain in the ass. Speaking of databases, you may have noticed disks are WAY slower than CPUs, RAM, etc. So the bottleneck for performance on well-designed systems is how much data you have to read from disk. If the data is twice as big, you have to read twice as much, and you get half the performance (assuming you didn't add a stupidity bottleneck elsewhere).
64 addresses were provide enough for 2 billion addresses per person. That's already a ridiculously large number.
A compromise position would have ben to *define* IPv6 addresses as 128-bit, and only assign addresses starting with 64 zero bits, for the next couple hundred years or so. That way you'd only need to *process* the lower 64 bits for the next century or so. 200 years from now, we'll have 256-bit CPUs running on 256-bit busses, so it'll be easy to start processing the higher bits at that time, if we need to.
> Is the Microsoft SQL Server thing the only reason why you think 64-bit would have been better?
SQL server is one example that 64-bit software, on 64-bit computers, natively handles 64-bit numbers, while 128 bit requires gymnastics.
Generally, I think 64 bits would have been more than enough. It would have allowed us to assign 2 billion addresses to each person. :) Not that we'd actually do that, obviously. We would have done perhaps 256 addresses (8 bits) for most end users, while reserving 80%-90% of the address space for future addressing plans. As you said, we using only 190.0.0.0.0.0.0.0/8 (or even 0:0:0/16) would have been plenty for the next 40-200 years.
At the time, we were running into 2GB limits on RAM on Windows disk sizes, and I predicted that the 2TB limit on MBR partitions would be a problem soon. Getting rid of MBR and switching to GPT has in fact been painful. I wanted to go ridiculously big with IPs so we'd never run into a similar problem.
A compromise position would have been to define them as 128 bits, and reserve everything but 0/64 for later use - so all addresses in use would start with 64 zero bits. You'd only have to process the lowest 64 bits, even though the first 64 zeroes technically exist. Then, a hundred years from now, we could announce that we'd start assigning 001:/64 ten years later, so software would need to start paying attention to that additional bit. Of course we'd have 256-bit CPUs by then.
I don't see that buying a cert gets you anything at all, for authenticating or communicating with your own clients. Why would you trust Versign more than you trust yourself? That's all buying a cert gets you - it's signed by them rather than being signed by you.
Protect your root CA, perhaps by storing it offline, and of course with a passphrase. Ideally for maximum security while maintaining convenience, you can use your root CA only to generate an intermediate cert, then use the intermediate to sign client certs. That way you can have your root locked up in a safe deposit box, since you never use it except once every few years.
I suppose buying does mean you don't have to install your root on new machines when you get them.
Any way to obtain a cert, for my network only, to authenticate my hosts and clients ... before going out on that damn internet?
That's called IEEE 802.1x. It's commonly used in corporate networks. You can set the router to allow no access until authenticated, or only allow them access to whatever resources are appropriate pre-auth.
IPv6 has five TRILLION /56 blocks.
There are enough /64 to give every person on earth 2,635,249,153 of them.
128 bits allows for HUGE numbers.
Long ago, when we were developing IPv6, I was part of the group who argued for 128 bit addresses rather than 64 bit. I've decided I was wrong. 64 bits would have been more than enough, and could be processed on 64-bit processors, in standard databases, without hassle. Since my side won the argument, we have 128-bit addresses, which are so big they are a pain in the ass in Microsoft SQL Server and elsewhere.
I absolutely understand why you'd say that. I've done that. However, the first thing the bad guys do when they want to break into a system is check for unpatched software. If you're running versions with known vulnerabilities, that makes things really easy for the bad guys.
So what can you do? For me, I use Linux and OS X. Yeah, if you're the type of person who enjoys fiddling with the registry, there's a learning curve. On the other hand, if you normally open browser when you sit down at your computer, Firefox, Chrome, and Opera are pretty much the same on any desktop OS.
> How do you know that ?
>> I spent 15 years developing and writing password / pass phrase security tools used on a huge number of web sites. I analyzed millions
Fifteen years of forty hours a week (and sometimes sixty) analyzing passwords stored in plain text, cracking passwords, creating tools to reduce bad passwords, etc. That's 38,000 hours studying password use.
> Do you store the passwords as plain text ?
Once *I* show up, passwords normally end up as salted SHA2 before long. It was salted MD5 for a LONG time, and that's actually still secure given a sanity limit on length, such as 256 characters, but I recommend SHA2 now, using crypt(pass, '$5$
There are plenty of critisisms of Google which are reasonable. Sane people might point out how much they data-mine their users, for example.
> So it is because no one uses them and not to be anti competitive pricks?
So you think the idea is that people will ditch Windows and Mac, switching to ChromeOS in order to get Chrome Apps, which few people have ever heard of? On what planet does that make any sense?
> yet they will be supported for the foreseeable future on Chrome OS?? Does that mean chrome OS sucks balls so badly it can't survive without this legacy tech to lock users in
ChromeOS doesn't HAVE native apps. The browser is the OS usrland. With Chrome Apps, ChromeOS wouldn't have *any* apps. So yeah it makes sense to keep Chrome Apps on ChromeOS, at least until it gets support for Amdroid apps, and for a generous transition period afterward.
Does ChromeOS suck balls? For my computer use case, yes it does. For my wife, it's perfect. It's exactly what she wants for her laptop.
The article you linked to strongly supports the opposite conclusion: that four unrelated words is quite unlikely to be cracked .
First, it explains that most of the 15,000 passwords were 6-9 characters, so the cracker was able to break 7,000 of them in just a few minutes. It starts getting much harder (slower) after that. In mosts cases, 7,000 passwords is plenty for a single site. When a bad guy wants more passwords, typically they quickly crack 7,000 mlre easy ones from another site. They don't waste hours cracking the hardest ones.
For the article, they went ahead and "wasted" a few hours trying to get some more difficult ones. They even got some that were two words. As the Ars article explains:
----
Because these attacks are capable of generating a huge number of guessesâ"the square of the number of words in the dictâ"crackers often work with smaller word lists or simply terminate a run in progress once things start slowing down.
------
That's the SQUARE of the dictionary, two words, and Ars explains crackers generally don't spend the hours to do that. "Correct horse battery staple" is FOUR unrelated words. Time required is proportional to dictionary size to FOURTH POWER. Ars didn't do that, nobody does that. Ars didn't even attempt three words, much less four.
Seriously I've spent fifteen years doing password security full time. I've done careful analysis on far more attacks than you've ever heard of.
> Yes, because electricity is free.
An Arduino in a sleep, wake cycle like that will have average power usage of about 0.005 watts. That's $0.005 per year (one penny every two years).
> There are a lot of dumb people here.
And we just found one of them.
> properly encrypt/salt the database to protect against offline attacks
Strong hashes, properly salted, ARE important*. However protection from offline attacks requires BOTH a strong salted hash (~encryption) AND a strong password.
A good hash means that given the hash, you can't get the password BY REVERSING THE HASH. However, if you can GUESS the password, there's no need to reverse the hash; you just guessed the password correctly.
* On Linux, you can get a strong salted sha256 hash by using crypt() with a hash of the format "$5$random$'.
Perl:
crypt($password, '$5$' . $random . '$'):
MySQL:
ENCRYPT( ?, CONCAT('$5$', ?, '$') ), password, randomstring
Once I had a system where the power management (sleep) couldn't be turned off, and we wanted to use it for digital signage. So in about eight lines of code I turned an Arduino into a USB mouse and set it to wiggle the cursor every 5 minutes, thereby preventing the system from going to sleep.
Later, I wanted to wanted to guess someone's PIN number over night, so with a few lines of code I set the Arduino to act as a USB keyboard and type in every possible PIN, waiting a few seconds between tries.
Now, Microsoft is willing to pay me to wiggle a mouse around and occasionally click. Hmm ... :)
Most of the celebrity hacks use exactly that vulnerability. How hard is it to find out what school Britney Spears went to, or what city she lived in?
I solution which still preserves the usefulness of the password reset questions is to answer them as if you were someone else. When it says "what high school did you go to?", pretend it says 'what high school did Chelsea Clinton go to?"
For example, if you wanted to password reset my account, you could easily find that that I went to a certain school. But that won't help, I fill in the information as if I were Colin Powell. Or maybe it's Abraham Lincoln. Or Justice Kennedy. Not knowing who I pretend to be, you can't determine how I'd answer those questions. On the other hand, if I ever forget my password, I can reset it by entering the name of Roger Waters' dog, rather than my own.
I spent 15 years developing and writing password / pass phrase security tools used on a huge number of web sites. I analyzed millions of brute force and dictionary attempts, as well as the offline tools.
In my professional opinion, where strength meters and password policies most often fail is that they greatly underestimate the importance of length. I recently encountered a site which required:
8-12 characters
Must include upper and lower case
Must include digits
Must include punctuation
Well we've all been taught since 1st grade or so that punctuation goes at the end of a sentence, and the first letter is capitalized, so most passwords on the system are of the form:
Capital lower lower lower lower lower lower digit punctuation.
Since the whole password is 8-12 characters, to get the digit and punctuation at the end you need a word that is 6-10 letters. Passwords are pretty predictable on that system. According to their policies, these are a good passwords:
Password1!
Passw0rd!
But this is a horrible password, that anybody can guess:
YRNKBV JSYZCXPRM ZOXADEKO JARQYTLY
OFOFBQ VKGDOSUE XFEUJQOHG TZBVHQIA WSBQHKVD SPIODPL
Allow and encourage long pass phrases. (Also encourage the term "pass phrase", not "password".) Making your pass phrase a tiny bit longer adds much more security than switching the number 0 for the letter O.
Ever heard of 2048 bit security? Or 1024 bit keys? That's how security professionals talk about strength - X number of bits. Those numbers refer to the LENGTH of the keys (passwords). That's what's most important above all.
See also:
http://imgs.xkcd.com/comics/pa...
> I'd be surprised if a kernel with a full driver stack would even fit by itself into 16 MB of flash
The full Redhat kernel and initrd is about 16MB - and contains drivers for most of the hardware Linux supports - RAID cards from 20 years ago, fibre channel, tons of network cards, etc. I'm pretty sure you won't be plugging a PCI-X RAID card into this $5 board, so why would you include those drivers in the boot image?
As someone else said, OpenWRT is pretty popular, and it's about 6MB.
Certainly the manufacturer's attorney would present the "we provide firmware at no charge" argument that you made. And plaintiff's attorney would say it doesn't matter because CFR says "It's guaranteed (but not really)" it's *deceptive*, which is unlawful regardless.
> it offends sound reason for something which is very clearly written to be "deceptive."
Consider:
LIFETIME GUARANTEE!!!!
(fix pages of fine print) Guarantee void if unapproved apps are installed. (more pages of fine print)
I would say that's deceptive. The clause voiding the warranty is written right there in the pages and pages of fine print - and it makes the "LIFETIME GUARANTEE!" claim deceptive because many users wouldn't actually have any guarantee under those terms. There may be no fundamental difference between "unapproved apps" and "unapproved firmware".
Your analysis of the statute is excellent. However, the code of federal regulations extends it a bit.
See 16 CFR 700.10 - Section 102(c).
https://www.law.cornell.edu/cf...
Quoting the Code of Federal Regulations:
--
such provisions are deceptive under section 110 of the Act, 15 U.S.C. 2310, because a warrantor cannot, as a matter of law, avoid liability under a written warranty where a defect is unrelated to the use by a consumer of âoeunauthorizedâ articles or service.
--
The phrase " warrantor cannot, as a matter of law, avoid liability ... where a defect is unrelated to the use by a consumer of âoeunauthorizedâ articles or service" may apply.
The quoted CFR text is saying why a manufacturer may not void a warranty due to repair by unauthorized service centers, or using unauthorized parts. The text itself does *not* limit the "cannot, as a matter of law" to only unauthorized parts, though, and it could well be argued that "unauthorized firmware" is an "unauthorized part" which may not void a warranty.
> So, I'm an adult, I borrow your phone to make a phone call or for another purpose - guess what - you do NOT have the legal right to monitor my communications.
If you said "you do not have a MORAL right" you'd get no argument from me. However, since you specifcally said "legal right", I'll inform you that you're quite mistaken. Dozens of people have tried to make that argument in court and they've consistently failed. The owner of a device or network has an absolute LEGAL right to monitor the usage of their own network amd devices. Whether they have a MORAL right is of course a matter of opinion.
Suppose I install one of those "web safe" filter software packages on my own computer. You borrow my computer, and try to load midgetsfucking.com. The software I installed on my computer logs the communication between my computer and midgetsfucking.com. You sue me. You'll not only LOSE, you'll probably lose by summary judgement, without even getting a trial. Why? Because the LAW, in the US at least, is that we each have a complete right to monitor our own stuff.
You are of course welcome to write rambling 800 procedures if you choose to do so. You won't while working for *me*, but in your software, do what you want.
In the kernel, we use the 24x80 rule. Lines no longer than 80 characters, and functions, from kerneldoc to ending brace, should normally be less than 24 lines, shorter if they are more complex. That leaves 20 lines for the function body - if the function isn't particularly complex. Complex stuff needs to be shorter. That rule works for us. We're happy, our 85 million users are happy. If you have 85 million happy users, keep doing what you're doing.
I wouldn't know the full details of which RDMS supports what types of updates, but they've always worked for me, when it makes sense for them to work. (Ie, obviously you don't update a sum.)
But I haven't tried too many different updates of user-friendly views, because I generally design my systems where updates / insertions aren't normally done manually by ad-hoc queries. People can retrieve data with ad hoc queries if they choose, no harm in that. For inserts and updates, I want those controlled by the software anyway, with all the proper validation.
Since the inserts are done by software, there's no problem writing the software to use the base tables. In fact, if you have even a general concept of objects in mind when writing the software (not necessarily full OOP), tables which reflect your objects may be easier than human-friendly views anyway.
So anyway, yeah I haven't updated THAT many views, and I'm glad I haven't.
> if I have [any] evidence, can I be ordered by the court
Yes.
> if I have hidden evidence that ties me to a crime, can I be ordered by the court
Still yes, plus the concealing is an additional crime:
Prosecution of Destroying or Concealing Evidence (Penal Code 135 PC)
A person knowing that any ... thing, is about to be produced in evidence upon a trial, inquiry, or investigation, authorized by law, willfully ...
destroys, erases, or CONCEALS the same
(quoting California law as an example of law in a typical Western jurisdiction)
Normally, the person in possession or control of the evidence would be ordered to actually bring the evidence to the court. Where that's impractical, they'll be ordered to make it available to attorneys for both sides, in whatever manner makes sense given the type of evidence.
Here's a another explanation by someone who has been studying these matters since 1977. When an interviewer asked Hillary Clinton if she kept detailed records of what she did in Washington, Clinton replied "Heavens no! It could get subpoenaed! I donâ(TM)t write anything down."