Reputation
18,172
Top tag
Next privilege 20,000 Rep.
Access 'trusted user' tools
Badges
13 71 136
Impact
~859k people reached

2d
comment My school wants to keep the details of our door authentication system a secret. Is that a good idea?
@alexw Arguably, yes. But without a key of some form - which will, almost invariably and inevitably, be human-reproducible with sufficient knowledge and skill - there is no way for anyone to access the system without allowing everyone to access the system. Therefore the system could be fully secure for CI, but completely fail A. Or it will exceed A and therefore fail CI. (From the "CIA triad".) Another common paraphrasing of Kerckoff's Principle specifically exempts keys (of which passwords are one type): "A system should remain secure, even if the enemy knows everything except the key."
Feb
4
comment My school wants to keep the details of our door authentication system a secret. Is that a good idea?
@Kos There. Semi-fixed it. Still no longer a direct quote, but at least there's a sentence in there that it roughly maps to as a paraphrase.
Feb
4
comment My school wants to keep the details of our door authentication system a secret. Is that a good idea?
@Nanoc See multiple comments in this thread, and the chunks that have been moved to chat. (And please post further discussion in one of those chat rooms.) Publicizing only makes the design more available to other people. It doesn't guarantee that those people will actually review it, or what their level of competency is in doing so. More importantly, you also have no guarantee of their intentions.
Feb
3
comment My school wants to keep the details of our door authentication system a secret. Is that a good idea?
This answer is very flawed in that it assumes publicizing the design will increase the number of people who are reviewing it, and who are both non-hostile and competent. It certainly makes the system more accessible to review by many people. But you cannot know how many people actually will bother to review it. Or how many of those people will even be knowledgeable, skillful, and thorough enough in their review to find any flaws. Or what the intentions will be of the people who do find flaws.
Feb
3
comment My school wants to keep the details of our door authentication system a secret. Is that a good idea?
If an enemy-exploitable flaw is found in the tanks, your combat effectiveness is only really compromised if the enemy in fact knows of the flaw. While Kerckoff says you have to assume this is possible, actually having the designs of the tanks public means you have to assume this is likely. Meanwhile, the timeline to come up with a fix or workaround for such flaws - then recall and upgrade/replace the fleet - will likely be measured in months.
Feb
3
comment My school wants to keep the details of our door authentication system a secret. Is that a good idea?
@JoãoPortela The risk to any design, in its current implementation, can only be increased by publishing details of that design. Tank armor is really a great analogy, albeit using camouflage as the obscurity layer in the analogy might not be best. Consider a nation already at war. Their tanks are deployed at the front lines in active combat. With open-source design, the enemy has practically equal information as you do when it comes to finding flaws in the tanks' construction or the armor's chemistry. And it's very possible that the enemy could dedicate more resources to finding them.
Feb
3
comment My school wants to keep the details of our door authentication system a secret. Is that a good idea?
Maybe in the question of "Is adding obscurity" you should change "adding" for "enforcing". If a single person designs a systems solely in their head, the design is naturally obscure without any additional effort. Even after the designer has documented the system in detail, the design remains reasonably obscure with practically zero additional effort so long as it remains solely within the designer's possession. Putting the design in a shared-access repository, however, threatens (but does not automatically break) the obscurity of the system. That's when effort is needed to enforce it.
Jan
29
comment How to choose a good (and easy to use) WiFi password?
@PacoHope But when you get into the 15-20 character range, you're already stretching the patience of anyone trying to enter the password on anything other than a full-size QUERTY keyboard. So, why not bump the strength up a notch anyway?
Jan
29
comment How to choose a good (and easy to use) WiFi password?
As for the password guidance, your thinking is somewhat flawed. Yes, length will generally increase entropy more than the size of the character set. But the increase is substantially smaller when you do limit your character set. It becomes even smaller if you start chunking characters together (i.e.: using words, instead of randomly selecting each character individually). Also, you're mis-interpreting my statement - I said strong passwords aren't human-memorable. This has nothing to do with their readability. (Of course they must be readable, otherwise we couldn't enter them.)
Jan
29
comment How to choose a good (and easy to use) WiFi password?
@PacoHope The problem is, partially, an X/Y issue. OP is complaining that he can't follow common password guidelines because it's a pain to enter them on anything other than a full-size keyboard. Easiest way to deal with that is to just not have to do it which, in the OP's scenario, is generally very possible and would also enhance the performance and security of their network.
Jan
28
comment How to choose a good (and easy to use) WiFi password?
@IanRingrose Auto-correct aside, Thorium's suggestion would be more efficient on keyboards that have features like Swype or predictive text. You could enter passwords effectively one word at a time, instead of one character at a time.
Jan
27
comment How to choose a good (and easy to use) WiFi password?
@drewbenn Fair enough point. But you should really disclaimer such suggestions up-front. Don't need anyone coming back here to complain after they mistakenly took it too seriously.
Jan
27
comment How to choose a good (and easy to use) WiFi password?
@drewbenn Please tell me that's sarcasm.
Jan
21
comment How should I securely type a password in front of a lot of people?
@Dan Skip the accelerometer. Just use the mic. Analysis of the sound could do just as well.
Jan
21
comment How many security-related websites/sofware/system/human brain will break when we get more than 10000 CVEs a year?
@schroeder I'm pretty sure they'll add another digit. Particularly since they said they would, and already have.
Jan
21
comment Can anyone help me build a combo file suitable for my problem?
Why are we assuming the password is only seven characters? The WiFi password is fourteen, and there does appear to even be enough room on the left side of the admin password for there to be an eighth character. I generally find eight characters to be a more common password length in general, as it used to be a very commonly-recommended (and still is a commonly-enforced) minimum.
Jan
21
comment Can anyone help me build a combo file suitable for my problem?
I suppose what @drewbenn and I are getting at is there's no need to put together a compiled program for the list generation, or pull in third-party tools. Built-in system shells and scripting languages will do just fine, and can be much more concise and less complex.
Jan
21
comment Can anyone help me build a combo file suitable for my problem?
PowerShell: $x=' 77k8 d'.ToCharArray();97..122+48..57|%{$x[0]=[char]$_;[char[]]'acdeghopqs'|%{$x[5]=$_‌​;$y=$x -join '';echo $y}} Perhaps could golf it a bit more if I were feeling particularly crafty.
Jan
20
comment How to find Windows version from the file on a remote system
Go ahead and brick it. It's well overdue.
Jan
4
comment Powershell opened up, switched to administrator mode and ran scripts all without me touching my computer. How worried should I be?
It's worth noting that the event log can be configured to capture a lot of useful information for troubleshooting these cases, but by default it usually doesn't.