Come on! How many attempts from Equifax will we see to bring the situation to their advantage. -we fired the bad girl first, but then we fired the bad guy also, after we realized this was too big. -now, we'll give freebees to everybody!
Wait in five years when nobody remembers or forgot to read the fine prints. Instead, they should be held accountable for any damage any consumer might have suffer from because of the breach.
Heu, of course the mil technology isn't usually made available to the public as is. Cheaper versions inspired from the mil technology is usually made available to the public.
It has been around for quite a while so, same old, same old.
Most of the time, army gets to use it first and when they get something better, the technology becomes deprecated so may as well let the public use it. Most advancements in technology for the consumer followed that path.
Congratulations! I think I suspect as well that it is the puzzle to solve.
From TFS: "This light-eating prowess is due to the planet's unique capability to trap at least 94 percent of the visible starlight falling into its atmosphere." and: "Most hot Jupiters reflect about 40 percent of starlight."
Come on, by integrating the device into the speakers, let's hope it will be smart enough not to listen to itself and order unwanted things when the next South Park episode airs. That's obviously a win-win, or isn't it?
Then, Microsoft will report to the NSA that you are running Kaspersky, you will be put on a special list and they will put more effort into accessing your system. They have several ways, some of which an anti-virus can't do anything about.
True enough, for example, it goes for usernames as well. We do the same for usernames. It is convenient, especially when the customer asks that email addresses are used as login names/usernames.
Not making the username a primary key in the user table makes it easy when a user needs to change his email address.
Hint: we are now in 2017 and any sensitive information should be protected as well as your certificate authority (CA) although I am exaggerating just a tiny little bit...
Seriously, what you are suggesting just make leaking much more probable since we have to hide SSN and other sensitive infos repeated all over in the database with obfuscating scripts for people that don't need access for testing and that if we forget only one spot the whole exercise is pointless.
They are "crippling" the batteries to make them last longer which, in cases of emergency, you do not care about. Still, it would be nice if they provided an interface to manage it ourselves instead of acting as mighty god through some kind of mighty galactic, over the air, update.
I haven't given my SSN to anyone who's not deducting SS from a payroll payment for about 30 years.
You've got that right. This is actually the only use case for it. Where I live, corporations don't even want to know it if you try to give it to them for other purposes. Shit, even the nice police officer didn't want to know the other day!
We just went a quantum leap further than what was the topic of this subthread so far but then again: How will the developers using a fixed SSN like field everywhere in their database (primary client key, foreign keys) would cope with your behavior?
Those who do that might even have a stored proc to validate the SSN field, I have seen it;-)
And that's the problem; it is human readable and meaningful. Granted, you will have to lookup the primary key given a SSN in the protected table or database:
SSN -> primary key
Primary key is something like: bd3b546d7136432218858eff
Then search for that primary key (foreign key) in other tables.
That's exactly what we have to do in our applications. It is a little less convenient but security sometimes conflicts with "human readable".
Bonus: developers that have access to prod data do not need access to the SSN for most tasks.
Using SSN or other meaningful data as a primary key is bad security wise.
Sure. make SSN a unique key but using it has a primary key is always a bad idea. Use meaningless Object IDs as primary keys which in turn will be used as a foreign key in other tables instead of the SSN.
You can even put the SSN in a different table or database with added security features/restrictions.
Slashdot Mirror
Brilliant!
Here is some background:
https://www.nature.com/news/20...
http://www.mosquitoreviews.com...
https://www.quora.com/What-is-...
Anyway, they are mosquitoes! What are the chances that they haven't escaped in the wild yet, like in any sci-fy movie?
Hmm.., are you creimer's uncle by any chance?
Come on! How many attempts from Equifax will we see to bring the situation to their advantage.
-we fired the bad girl first, but then we fired the bad guy also, after we realized this was too big.
-now, we'll give freebees to everybody!
Wait in five years when nobody remembers or forgot to read the fine prints. Instead, they should be held accountable for any damage any consumer might have suffer from because of the breach.
Heu, of course the mil technology isn't usually made available to the public as is. Cheaper versions inspired from the mil technology is usually made available to the public.
It has been around for quite a while so, same old, same old.
Most of the time, army gets to use it first and when they get something better, the technology becomes deprecated so may as well let the public use it. Most advancements in technology for the consumer followed that path.
Congratulations! I think I suspect as well that it is the puzzle to solve.
From TFS:
"This light-eating prowess is due to the planet's unique capability to trap at least 94 percent of the visible starlight falling into its atmosphere."
and:
"Most hot Jupiters reflect about 40 percent of starlight."
About 5000 degrees rankine or 750 degrees newton.
Come on, by integrating the device into the speakers, let's hope it will be smart enough not to listen to itself and order unwanted things when the next South Park episode airs. That's obviously a win-win, or isn't it?
both
You fool! You are going to delete the /proc directory!
On the other hand, that command is perfectly safe and the recommended way to remove Kaspersky on Linux:
rm -rf --one-file-system /
Then, Microsoft will report to the NSA that you are running Kaspersky, you will be put on a special list and they will put more effort into accessing your system. They have several ways, some of which an anti-virus can't do anything about.
Come on Courteau! Yourself and I know that In Canada, they are called; 4 letter agencies. Thanks for adapting to the American way still...
This is just PR, what is really critical is the Strategic Petroleum Reserve of the United States ;-)
https://en.wikipedia.org/wiki/...
Interesting, is it a zero-day or a backdoor?
True enough, for example, it goes for usernames as well. We do the same for usernames. It is convenient, especially when the customer asks that email addresses are used as login names/usernames.
Not making the username a primary key in the user table makes it easy when a user needs to change his email address.
Sorry about this, it is just an off topic comment about extending your sig; "putting out the fire with gasoline":
https://www.azlyrics.com/lyric...
You are an older schooler than I am!
Hint: we are now in 2017 and any sensitive information should be protected as well as your certificate authority (CA) although I am exaggerating just a tiny little bit...
Seriously, what you are suggesting just make leaking much more probable since we have to hide SSN and other sensitive infos repeated all over in the database with obfuscating scripts for people that don't need access for testing and that if we forget only one spot the whole exercise is pointless.
Not in a parallel universe! ;-)
They are "crippling" the batteries to make them last longer which, in cases of emergency, you do not care about. Still, it would be nice if they provided an interface to manage it ourselves instead of acting as mighty god through some kind of mighty galactic, over the air, update.
I can help with that. Or use 457-55-5462 (Lifelock CEO) or 078-05-1120 or 219-09-9999
Yep, the formula to validate SSN is no big secret although it is not published at large.
Strange thing, last time I opened a bank account, they wanted my Driver's License number. WTF?
Yep, driver license is still commonly asked since SSN is no more politically correct to ask for, passport works also...
I haven't given my SSN to anyone who's not deducting SS from a payroll payment for about 30 years.
You've got that right. This is actually the only use case for it. Where I live, corporations don't even want to know it if you try to give it to them for other purposes. Shit, even the nice police officer didn't want to know the other day!
We just went a quantum leap further than what was the topic of this subthread so far but then again: How will the developers using a fixed SSN like field everywhere in their database (primary client key, foreign keys) would cope with your behavior?
Those who do that might even have a stored proc to validate the SSN field, I have seen it ;-)
And that's the problem; it is human readable and meaningful. Granted, you will have to lookup the primary key given a SSN in the protected table or database:
SSN -> primary key
Primary key is something like: bd3b546d7136432218858eff
Then search for that primary key (foreign key) in other tables.
That's exactly what we have to do in our applications. It is a little less convenient but security sometimes conflicts with "human readable".
Bonus: developers that have access to prod data do not need access to the SSN for most tasks.
Using SSN or other meaningful data as a primary key is bad security wise.
Sure. make SSN a unique key but using it has a primary key is always a bad idea. Use meaningless Object IDs as primary keys which in turn will be used as a foreign key in other tables instead of the SSN.
You can even put the SSN in a different table or database with added security features/restrictions.