I may be a bit OCD about passwords and security - 30 years USAF and NASA have bent my brain a bit. Typing in pwds a lot doesn't bug me cuz I know my pwd mgt tool is safe because it's out of reach of hackers.
It's called pencil and paper. I have a notebook, and all pwds are encoded there. I have 4 simple rules for modifying what I write into what I type in. An example rule you could use is "Real pwds use only even digits; Passwords are written with all ten digits, odd digits are ignored". 2-4 simple rules will make it unhackable even for someone with physical control of passbook. (Never write down the rules - keep them in yer head).
To keep the rules fresh, use different passwords and uids for every single app or website possible. You'll always be rehearsing the rules in yer head, you won't forget them.
Here's an example from my current set: pwd= "RhinoPott=amus" Rule 1,3
I'll bet you can't guess the real password in 10,000 tries. You don't know rules 1 or 3, which modify what's written. Go ahead, give me 10000 tries in a text file - I'll let you know if you get it.
This really really works - I've been doing this way since the 1980's, and haven't misplaced a properly coded pwd yet.
The cop's job is to get people in trouble. In a perfect world, it's the people that deserve trouble that get it, but even then, the very best you can hope to get from the police is to be left alone. There's no need to characterize cops as bullies or incompentent - even the good cops have to look at citizens as potential targets. The course of action when the cops want to talk to you is immediately get legal counsel, then follow that counsel in dealing with the police.
As for us v them - police are no longer part of the communities they patrol. They only see the worst in the community, and that biases their perspective. Also, they are trained and equipped more as an invading army than as "public servants", so seeing them as the enemy is an obvious and natural result.
is that a person's opinion is somehow relevant to how they perform professionally. Just disagreeing with your employer is never just cause for firing the employee - the alternative is a cadre of 'yesmen' who cause stagnation through lack of new perspective and ideas. An employer who refuses to accept any kind of dissent is one who dooms his organization to mediocrity.
The plan was to move more slowly, using airplane-like vehicles to get into orbit. Ultimatley, the moon was the goal. JFK's challenge derailed the early shuttle program in the late 1950s-early 1960s. Use of 'disintegrating totem poles' replaced the development of reusable spacecraft parts. The shuttle program that we got after Apollo was another quick-easy-expensive program, rather than the result of 20+ years of development. sorry no cites, but I have little time right now for this....mebbe later. (google should find bunches - look up project dynasoar, X-15, etc)
.....air conditioner repairman in a few interactive web sessions per week for a year?
chef at a 5 star greasy spoon? TV sitcom writer ? What professionals (esp unions) would be insulted by such a trivializing of their careers?
Computers are the most complex machines every devised. How good could such a 'professional' be?
(claimer: I am pro developer)
I worked 30 years in astronaut training facility (full-fidelity simulators), and wrote many many documents on software that I wrote. I always kept my own digital copies, of course. Over the years, the contracts changed hands many times, and different document systems were implemented, and "all" documents were "always" converted from old to new. I was never able to later re-locate *any* document I had submitted to *any* of the document systems. So my copies of my documents were the only ones that actually existed that I knew of. This included meeting minutes, peer review notes, design and 'as-delivered' documents. So I think institutional amnesia is more the norm, and actual memory beyond 3-5 years is rare.
"each phase of the code compilation process is exposed as a service that can be consumed by other applications."
How bout if the 'other app' is a web browser window? TFA suggests this will be possible with MS's product.
I was thinking cpu-specific, not OS-independent. Sorry for ambiguity. CPU-specific compilation may allow for use of idiosyncratic features/bugs in the production of invasive code, something a little more difficult if the target hardware is unknown.
Now malware can be shipped in various partially-compiled steps and in different packaging (one,two,three modules, arriving from different vectors, etc), making detection harder, and can then be compiled targetting the cpu it lands on. Oh, what a fricken great IDEA! platform-independence for malware just got easier! It''s really getting hard to distinguish between the bad guys and producers of ideas like this.
try this: use several unrelated dictionary words, strip the vowels, and make it look like math:
prpl=rckt*grnt (purple = rocket * granite)
or some similar small set of rules. passowrds are secure, you only have to remember three words, and once you've memorized the simple rules, you can even write down the three words without compromising the real password. You also get longer paswords (14 chars is current recommendation).
Approx 20 years ago I wrote code for a system at work to do this, list was 100's of possible, including acronyms from work, userids and real names, stupid stuff like variations of 'password', etc. We had to do it cuz the customer (nasa) considered it "old hat, everyone else is doing this, why aren't we?"
"Gunny! Double the charge in the clue cannon!"
Gunny: "Aye,aye cap'n!"
Capn: "And stand ready to reload. I think it's gonna take more than just a few rounds!"
The filter I propose isn't based on "submitted userid == any valid userid" but "submitted userid (is X% similar to) any valid userid". X would be a tunable value. In spam email filters, this usually works out to "if incoming email (is less than 20% similar to) previously accepted emails" or some such. It turns out that spam emails, even if containing dictionary words, still don't resemble human communications when bayesian statistics are applied to it.
Since the attacker doesn't know what userids are valid, the chance of any guessed userid being more than a few percentage points similar to a valid userid is vanishingly small.
Try it - pick a thousand "valid userids" out of the dictionary. Now pick a thousand more, omitting variations like "library - librarian". How many attempts will have more than a few characters in (almost) the same position and (almost) the same order as the "valid userids"?
The reason to use the userid list is because it is invisible to the attacker. The only result the attacker sees is suddenly one of the bots is blocked from the target host. No reason why, and no indication which of the last 20 or 100 or so userid attempts were "way off" and thus contributed to the decision to block.
A valid login attempt with a typo in the userid will be right in all but 1 or 2 characters nearly all the time. The bruteforce attacker will be wrong by more than 1 or 2 characters nearly all the time. Statistically, that's significant.
Since the block doesn't happen because of a single match or failure to match the list, the attacker learns nothing. The attacker doesn't even know the bayesian testing is occurring, thus the attacker would have no knowledge of which its attempted userids was valid or close to valid.
It doesn't matter even if the attacker knows this filter is in place. Blocking the entire botnet will be a function:
Block = (v/b)*p
Where v == count of valid userids
b == count of hosts in the botnet,
p == average number of attempts required to guess a password.
B == point at which entire botnet is blocked.
With strong 8 character userids and passwords, the botnet would require billions of hosts in order to breech the system before being blocked.
I wasn't talking about the product to use to do it, but a detection approach that isn't present in any product I know of.
I described how to detect a specific kind of behavior that would be unique to the attack and the attacker, and to which attackers can not mount a meaningful countermeasure. Implementing the filter requires statistical analysis of not just incoming data, but also resident data (the userid list).
Would a bayesian filter work on this? The filter would match bad userids against the set of valid ones; bad userids that do not resemble any valid id by more than X% will score a demerit against the host that submitted the bad ID. Enough bad ids will probably identify an attacking bot, which can then be blocked. This is a slow defense, but the attack itself is slow and will probably statistically require far more attempts than a bayesian filter requires to identify the attacker.
Since the attacker doesn't know the set of valid userids on the target system, it's hard to see how this could be countered. Spam authors know how normal email looks, but still can't defeat bayesian spam filters.
and use the FORTRAN source to port to JS. Sure, it's like crayons and a big chief tablet, but IIRC that's what Colossal Cave was first coded in. I know I ran across a FTN version in 1979.
But just enough to pay for the litigation hassle. Judges (usually) pay close attention to the level of courtesy and maturity shown by the litigants prior to filing the suit. By bending over backwards being nice and trying to work things out, FSF has set themselves on the moral high ground, which (usually) pays back big time in the judge's decision.
If sufficient 'quality' checks are added to avoid the costs associated with mistakes, the process is 'factoring in' the cost as a normal operating expense. If the checks, testing, paperwork cost more hours to perform 'correctly' than a bug itself would cause when it occurs, then the cost of bugs is added to every release whether the bugs occur or not.
This is paying for bugs the hard way. This destroys the value produced by the good programmers by adding back the costs their good code saves. It's much easier to reach this threshold than most (non-programmer) managers realize.
The advantage seen by managers is a 'better' management of the process due to predictable schedules. The predictability comes from slack in the schedule created by low-bug software that doesn't cause delays. Illusionary schedule gain is then used up in the next release that has a (statistically insignificant) increase in bugs. Over time, it looks better but costs more.
No it isn't. Enterprise was used for ALT (Approach and Landing Tests) in 1980's, pre-first launch. Technically, it has 'flown', but not as part of a launch vehicle or into space. It was 'drop tested'.
Flight software testing only requires the computers and related avionics; currently, some of that is in Bldg 9 at JSC (I think - it's been years since I was there). Flight software testing is done in a variety of ways, including running it in the astronaut training simulators on emulated and actual flight hardware. One of the early flights, STS 2 or 3 IIRC, was delayed a coupla days cuz a bug in flight software. It had occurred in the simulator as well, but nowhere else. Flight crews didn't yet trust the realism of the GNC configuration in the simulator, so the simulator was considered the cause of the bug.
The SMS became a part of the testing process for flight software after that.
Again, this is personal comment only, does not reflect, and I am not authorized to speak for my employer or NASA.
Slashdot Mirror
I may be a bit OCD about passwords and security - 30 years USAF and NASA have bent my brain a bit. Typing in pwds a lot doesn't bug me cuz I know my pwd mgt tool is safe because it's out of reach of hackers.
It's called pencil and paper. I have a notebook, and all pwds are encoded there. I have 4 simple rules for modifying what I write into what I type in. An example rule you could use is "Real pwds use only even digits; Passwords are written with all ten digits, odd digits are ignored". 2-4 simple rules will make it unhackable even for someone with physical control of passbook. (Never write down the rules - keep them in yer head).
To keep the rules fresh, use different passwords and uids for every single app or website possible. You'll always be rehearsing the rules in yer head, you won't forget them.
Here's an example from my current set: pwd= "RhinoPott=amus" Rule 1,3
I'll bet you can't guess the real password in 10,000 tries. You don't know rules 1 or 3, which modify what's written. Go ahead, give me 10000 tries in a text file - I'll let you know if you get it.
This really really works - I've been doing this way since the 1980's, and haven't misplaced a properly coded pwd yet.
The cop's job is to get people in trouble. In a perfect world, it's the people that deserve trouble that get it, but even then, the very best you can hope to get from the police is to be left alone. There's no need to characterize cops as bullies or incompentent - even the good cops have to look at citizens as potential targets. The course of action when the cops want to talk to you is immediately get legal counsel, then follow that counsel in dealing with the police.
As for us v them - police are no longer part of the communities they patrol. They only see the worst in the community, and that biases their perspective. Also, they are trained and equipped more as an invading army than as "public servants", so seeing them as the enemy is an obvious and natural result.
is that a person's opinion is somehow relevant to how they perform professionally. Just disagreeing with your employer is never just cause for firing the employee - the alternative is a cadre of 'yesmen' who cause stagnation through lack of new perspective and ideas. An employer who refuses to accept any kind of dissent is one who dooms his organization to mediocrity.
Swiggle D. Leggboan. Go ahead, look me up. I don't know the direct-to-profile link, sorry no clickie-poppie.
The plan was to move more slowly, using airplane-like vehicles to get into orbit. Ultimatley, the moon was the goal. JFK's challenge derailed the early shuttle program in the late 1950s-early 1960s. Use of 'disintegrating totem poles' replaced the development of reusable spacecraft parts. The shuttle program that we got after Apollo was another quick-easy-expensive program, rather than the result of 20+ years of development. sorry no cites, but I have little time right now for this....mebbe later. (google should find bunches - look up project dynasoar, X-15, etc)
success = failures + 1; // how to be good at any job.
.....air conditioner repairman in a few interactive web sessions per week for a year? chef at a 5 star greasy spoon? TV sitcom writer ? What professionals (esp unions) would be insulted by such a trivializing of their careers? Computers are the most complex machines every devised. How good could such a 'professional' be? (claimer: I am pro developer)
I worked 30 years in astronaut training facility (full-fidelity simulators), and wrote many many documents on software that I wrote. I always kept my own digital copies, of course. Over the years, the contracts changed hands many times, and different document systems were implemented, and "all" documents were "always" converted from old to new. I was never able to later re-locate *any* document I had submitted to *any* of the document systems. So my copies of my documents were the only ones that actually existed that I knew of. This included meeting minutes, peer review notes, design and 'as-delivered' documents. So I think institutional amnesia is more the norm, and actual memory beyond 3-5 years is rare.
"each phase of the code compilation process is exposed as a service that can be consumed by other applications."
How bout if the 'other app' is a web browser window? TFA suggests this will be possible with MS's product.
I was thinking cpu-specific, not OS-independent. Sorry for ambiguity. CPU-specific compilation may allow for use of idiosyncratic features/bugs in the production of invasive code, something a little more difficult if the target hardware is unknown.
Now malware can be shipped in various partially-compiled steps and in different packaging (one,two,three modules, arriving from different vectors, etc), making detection harder, and can then be compiled targetting the cpu it lands on. Oh, what a fricken great IDEA! platform-independence for malware just got easier! It''s really getting hard to distinguish between the bad guys and producers of ideas like this.
Astronomers, as a group, are every bit as smart as rocket scientists. I've worked with both at NASA. I think they can handle the name change.
I searched for 'faster than light' on the CERN website, got articles posted in 2012, 2014. They put this new discovery to work right away!
try this: use several unrelated dictionary words, strip the vowels, and make it look like math: prpl=rckt*grnt (purple = rocket * granite) or some similar small set of rules. passowrds are secure, you only have to remember three words, and once you've memorized the simple rules, you can even write down the three words without compromising the real password. You also get longer paswords (14 chars is current recommendation).
Approx 20 years ago I wrote code for a system at work to do this, list was 100's of possible, including acronyms from work, userids and real names, stupid stuff like variations of 'password', etc. We had to do it cuz the customer (nasa) considered it "old hat, everyone else is doing this, why aren't we?"
Pidoma == Pulled It Directly From My... uh... Mid Air.
"Gunny! Double the charge in the clue cannon!"
Gunny: "Aye,aye cap'n!"
Capn: "And stand ready to reload. I think it's gonna take more than just a few rounds!"
The filter I propose isn't based on "submitted userid == any valid userid" but "submitted userid (is X% similar to) any valid userid". X would be a tunable value. In spam email filters, this usually works out to "if incoming email (is less than 20% similar to) previously accepted emails" or some such. It turns out that spam emails, even if containing dictionary words, still don't resemble human communications when bayesian statistics are applied to it.
Since the attacker doesn't know what userids are valid, the chance of any guessed userid being more than a few percentage points similar to a valid userid is vanishingly small.
Try it - pick a thousand "valid userids" out of the dictionary. Now pick a thousand more, omitting variations like "library - librarian". How many attempts will have more than a few characters in (almost) the same position and (almost) the same order as the "valid userids"?
The reason to use the userid list is because it is invisible to the attacker. The only result the attacker sees is suddenly one of the bots is blocked from the target host. No reason why, and no indication which of the last 20 or 100 or so userid attempts were "way off" and thus contributed to the decision to block.
A valid login attempt with a typo in the userid will be right in all but 1 or 2 characters nearly all the time. The bruteforce attacker will be wrong by more than 1 or 2 characters nearly all the time. Statistically, that's significant.
Since the block doesn't happen because of a single match or failure to match the list, the attacker learns nothing. The attacker doesn't even know the bayesian testing is occurring, thus the attacker would have no knowledge of which its attempted userids was valid or close to valid. It doesn't matter even if the attacker knows this filter is in place. Blocking the entire botnet will be a function:
Block = (v/b)*p
Where v == count of valid userids
b == count of hosts in the botnet,
p == average number of attempts required to guess a password.
B == point at which entire botnet is blocked.
With strong 8 character userids and passwords, the botnet would require billions of hosts in order to breech the system before being blocked.
I wasn't talking about the product to use to do it, but a detection approach that isn't present in any product I know of.
I described how to detect a specific kind of behavior that would be unique to the attack and the attacker, and to which attackers can not mount a meaningful countermeasure. Implementing the filter requires statistical analysis of not just incoming data, but also resident data (the userid list).
Would a bayesian filter work on this? The filter would match bad userids against the set of valid ones; bad userids that do not resemble any valid id by more than X% will score a demerit against the host that submitted the bad ID. Enough bad ids will probably identify an attacking bot, which can then be blocked. This is a slow defense, but the attack itself is slow and will probably statistically require far more attempts than a bayesian filter requires to identify the attacker.
Since the attacker doesn't know the set of valid userids on the target system, it's hard to see how this could be countered. Spam authors know how normal email looks, but still can't defeat bayesian spam filters.
and use the FORTRAN source to port to JS. Sure, it's like crayons and a big chief tablet, but IIRC that's what Colossal Cave was first coded in. I know I ran across a FTN version in 1979.
But just enough to pay for the litigation hassle. Judges (usually) pay close attention to the level of courtesy and maturity shown by the litigants prior to filing the suit. By bending over backwards being nice and trying to work things out, FSF has set themselves on the moral high ground, which (usually) pays back big time in the judge's decision.
If sufficient 'quality' checks are added to avoid the costs associated with mistakes, the process is 'factoring in' the cost as a normal operating expense. If the checks, testing, paperwork cost more hours to perform 'correctly' than a bug itself would cause when it occurs, then the cost of bugs is added to every release whether the bugs occur or not.
This is paying for bugs the hard way. This destroys the value produced by the good programmers by adding back the costs their good code saves. It's much easier to reach this threshold than most (non-programmer) managers realize.
The advantage seen by managers is a 'better' management of the process due to predictable schedules. The predictability comes from slack in the schedule created by low-bug software that doesn't cause delays. Illusionary schedule gain is then used up in the next release that has a (statistically insignificant) increase in bugs. Over time, it looks better but costs more.
No it isn't. Enterprise was used for ALT (Approach and Landing Tests) in 1980's, pre-first launch. Technically, it has 'flown', but not as part of a launch vehicle or into space. It was 'drop tested'.
Flight software testing only requires the computers and related avionics; currently, some of that is in Bldg 9 at JSC (I think - it's been years since I was there). Flight software testing is done in a variety of ways, including running it in the astronaut training simulators on emulated and actual flight hardware. One of the early flights, STS 2 or 3 IIRC, was delayed a coupla days cuz a bug in flight software. It had occurred in the simulator as well, but nowhere else. Flight crews didn't yet trust the realism of the GNC configuration in the simulator, so the simulator was considered the cause of the bug.
The SMS became a part of the testing process for flight software after that.
Again, this is personal comment only, does not reflect, and I am not authorized to speak for my employer or NASA.