Hacker News .hnnew | past | comments | ask | show | jobs | submit | bitwizzle's commentslogin

Now is the time for vendors to consider implementing a duress password. Upon entering your duress password the user is presented with a fake profile, or perhaps everything could just be wiped. I'm not sure how well this would play out in the real world, but it's one of the best things protections I could imagine if you want to carry sensitive data across borders.


I really wish mobile device vendors would add support for multiple unlock modes. E.g.:

* "Me mode" that unlocks everything.

* "Kid mode" that only allows one's kid access to pre-approved apps and features.

* A "lend to a stranger to make a call" mode that is a lot like the kid mode, but it also causes the phone to start broadcasting its GPS location frequently (and refuse to turn off [though it might fake it]) in case the stranger steals it.

* An "under duress" alternate PIN that unlocks an alternate profile full of nothing but benign activity, with no indication of (or access to) the encrypted real profile. Once in this mode, the phone cannot unlock normally without a non-phone 2-factor authentication (e.g., email).

All but the last could use the normal PIN, perhaps with different "submit" buttons. I would also love to see the same thing on ATMs, where an alternate "I'm being robbed" PIN will show a fake, low balance in the account and limit withdrawal to that value.


That idea is so good. The ATM could also sound a silent alarm, just like some home alarms do. The phone could maybe even start recording all interactions and automatically submit to something like ACLU.


The silent alarm idea is excellent. Perhaps this could also trigger the machine to scan and store the serial numbers of the dispensed bills, so the bills themselves could become evidence of the crime.


That ATM idea sounds pretty cool honestly.

Applying it to phones seems a bit unrealistic, given that so few people will actually use those features.


It's not security by obscurity. It's security by diversity, which is arguably a good thing.


Security by obscurity is also, arguably, a good thing by your logic.

Seeing as someone didn't get it... Security by diversity is secure in the same way something is secure by obscurity. In other words, its not, its just harder to find the insecurity.


Security by diversity means that any extreme rare vulnerability will only hit a few individuals. The trade is that there will be more unique vulnerabilities found.

In risk management, having risk spread out is general a favored tactic. Same is true in biology. The chance that remote memory access vulnerability is so rare, that 200 libraries (if equally used) would lower the effected number of people with a factor of almost 200.


I'm not exactly disagreeing with you here. I just dont understand how that is different from obscuring your attack surface making you less likely to be targeted by some sort of mass generic attack vector.

Nobody argues security through obscurity doesn't work in some form, we argue that it doesn't make you secure as a matter of fact. Much like using some obscure SSL implementation. It sure does have the net effect of making you less likely to fall victim but that isn't security that is obscurity.


It's not about "obscure SSL implementations", it's "alternative implementations", and letting different projects theoretically play off each others strengths and mitigating consumer risk similar to investing in an index or mutual fund rather than all-in with any single entity.

Also, there's nothing wrong with security through obscurity, but please don't let that be your only security.


As someone else has already pointed out that could be better classified as risk management than the way I originally put it.

The problem with security through obscurity is that it is not security. Kind of what people mean when they bring it up.. At least in my circles anyway.

It is fine to have security through obscurity but you can't, much like the alternative implementation scenario claim it makes you more secure as a result. Its exactly like when apple claimed they were more secure and couldnt get viruses like their PC counterparts.

That is what I was trying to bring to the conversation when I made my first post. I get the feeling were starting to move off topic / split hairs over words now so I'm going to leave it at that I dont think I can explain myself any further.


> The problem with security through obscurity is that it is not security.

I'm sure we'd like each other if we sat down over coffee, and would find more in common than, not, but I have to politely disagree with you here. It does offer a degree of security, and I can give you a challenge that is measurably testable:

Move your sshd from 22 -> (eg) 222, and watch the hack attempts disappear.

Now, in the context of "remote logins", moving telnet from 23 -> 223 offers a _degree_ of security from a casual person connecting to port 23 and trying their luck, but we all know that telnet is a poor remote access tool these days. Switching from telnet to ssh is security by technology (encryption, mechanism (ie: keys vs passwords)). Moving sshd from port 22 -> 223 keeps that many more people from knocking on the door, no matter what other security is setup. "Security by Obscurity" adds to "Proper" security.

Surely we're both on the same page that, given better options, security solely through obscurity is stupid.


Then you're advocating risk management, and not security.


Risk management and security is two sides of the same coin.

Lets make an analogy of an investor. If person invest in a single company and it goes bankrupt, the investors might loose his roof over his head and the food on the table. This in turn effects his personal security.

In order to mitigate this risk, he uses risk management to diversify his risks. He might not be able to spend the same amount of time per investment and this increasing the general risk, but high risk events like bankruptcy is spread out and is unlikely to cause a large impact.


It's not harder to find the insecurity. At all.

It's harder to get a generic exploit that will give you access to a lot of targets. But I'd argue that finding an exploit for a particular target would be easier.


Apps on your phone (that have the right permissions) already have the ability to do everything that this app does. Did you personally audit the source code/reverse engineer every app to find out whether it is abusing these privileges? Do you trust the author of every privileged app on your phone?

This is the reality of smart phones. The only difference with this app is that it is upfront about profiling you. Coverscreen has a lot to lose if it anyone finds out they are misusing your data. You should be more worried about apps that aren't telling you how you're being profiled/monitored.


For those of us still using bash, "set -o vi" is analagous. I would be interested in hearing about customizing it in ways like this article.


While it's true that you should disable compression, most browsers disable it client-side now so this isn't a huge issue. As for BREACH, HTTP compression has a huge performance benefit, so it's not really feasible to disable it. Unfortunately, it's pretty difficult to protect the attack using other methods.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: