[Crypto-chi] Security Through Obscurity

Fri Feb 20 15:56:22 CST 2015

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Not all forms of security through obscurity are bad (per say). Doing
_only_ security through obscurity is bad. For example, if you permit
have PermitRootLogin yes set in your /etc/ssh/sshd_config, moving your
ssh port to port 55 wouldn't make your webserver more secure. However
if you properly secure SSH _and_ move it to a port that's not port 22,
you reduce login attempts on your webserver by a lot. That's a good thing.

Daniel Miessler wrote a great blog post[0] about it. Mason makes some
great points, but I would argue its a valid security layer.

Freddy

[0] https://danielmiessler.com/study/security_and_obscurity/

On 02/19/2015 08:39 AM, Mason Donahue wrote:
> Another data point: physical locks. There was a huge outcry at the
> beginnings of locksport about "how dare you point out how insecure
> these things are, you're helping the criminals" followed by the
> observation that criminals already know how to do this, and if more
> people understood how weak a lock was, they'd plan contingencies
> around it. Same thing with the Bic pen tubular lock kerfuffle for
> Kryptonite's bike locks. (A Bic pen was the right diameter and a
> soft plastic, so it basically made a perfect imprint on the pins
> and would work as a key.)
> 
> NYC's firemen's keys are an example: you can buy them 
> (http://nypost.com/2012/10/01/lock-away-these-nyc-keys/ 
> https://www.schneier.com/blog/archives/2012/10/master_keys.html),
> but the NYC master key is called a '2642' key because, well, that's
> the bitting code. You can also just make one. People are(were?)
> arguing that selling the key is some kind of horrible
> terrorist-helping exercise, when all it takes is someone buying a
> standard Yale blank and a metal file. The security of NYC elevators
> is based on people not knowing (or not abusing the knowledge) that
> they all have a common master key that you can buy from a hardware
> store key shop. Rather than fix the problem, they asked the dude
> making them to stop. The news stories, most with pictures of the
> keys in question for easy replication, did more to expose the
> vulnerability of the design than a dude selling them on eBay 
> could.
> 
> Another data point: early electronic crypto designs. The Geffe
> paper about using LFSRs as a keystream with an initial seed was
> called 'How to Protect Data with Ciphers that are Really Hard to 
> Break,' but it turns out that they weren't (vulnerable to 
> known-plaintext, among other weaknesses).
> 
> (From a paper 
> (http://www.uobjournal.com/papers/uobj_paper_2014_51841529.pdf)
> about that shift cipher:
> 
> The main goal of this paper is to find the initial values of every
> LFSR in the system depending on the following information: 1. The
> length of every LFSR and its feedback function are known. 2. The CF
> is known. 3. The output sequence S (keystream) generated from the
> LFSRS is known, or part of it, practically, that means, a probable
> word attack being applied (Schneier, 1997).)
> 
> Another data point: WWII ciphers. Generally, people who do this for
> a living learned about it during WWII with Enigma, etc. The idea is
> that if your cryptosystem assumes that the details of the
> cryptosystem must be unknown in order for it to be secure, it isn't
> -- Enigma was broken in part because of people successfully
> recovering an intact machine and reverse-engineering it, though the
> Germans' use of a key per day instead of a key per message 
> certainly made things easier 
> (http://en.wikipedia.org/wiki/Cryptanalysis_of_the_Enigma). Modern
> systems are designed so that the keyspace required to search, even
> with full knowledge of the design of the system, is so large as to 
> be infeasible precisely because of things like this.
> 
> --Mason
> 
> On 2/18/15 10:28 PM, Dan Massoglia wrote:
>> Thx both. Another application I think is some of the wi-fi or
>> bluetooth components being added to cars, I think in some cases
>> for unlocking (?). I remember reading about that a while ago. I'm
>> interested in this in part to try to bridge a gap between privacy
>> people and security folks. When some privacy scholars say
>> "obscurity" they act as if the words stay in a privacy context
>> (which is supposed to exist in the abstract) without security
>> comment or consideration. I thought the disconnect might form
>> connections.
>> 
>> On Wed, Feb 18, 2015 at 10:25 PM, Peter Baumgarten 
>> <me at peter-baumgarten.com <mailto:me at peter-baumgarten.com>>
>> wrote:
>> 
>> A good example I can think of is wifi. Instead of using something
>> like WPA2 to secure an access point one can instead to just not
>> broadcast the SSID. The wifi network will not show up on a list
>> of networks to connect to but one can just manually enter in the
>> SSID and then they can connect. I do not if that helps you Dan,
>> but it is the example I think of when I hear security through/by
>> obscurity and that it is bad.
>> 
>> On Wed, 2015-02-18 at 22:18 -0600, brian wrote:
>>> I really don't know any good examples, though, I was able to
>>> find this techdirt article from last year about healthcare.gov
>> <http://healthcare.gov>.
>>> 
>>> 
>> https://www.techdirt.com/articles/20140820/15163928269/white-house-going-with-security-obscurity-as-excuse-refusing-to-release-healthcaregov-security-details.shtml
>>
>> 
> 
>>> Hope that helps you start the search.
>>> 
>>> -Brian
>>> 
>>> On 02/15/2015 03:58 PM, Dan Massoglia wrote:
>>> 
>>>> Hey CP Ppl,
>>>> 
>>>> 
>>>> Does anyone have good information--preferably academic for
>>>> what I'm doing right now but security blogs or something cool
>>>> too--about Security through obscurity. We touched on it
>>>> briefly at CryptoParty. H8 sending out this ask without more
>>>> but I'm at a loss for starting on the security stuff
>>>> sometimes. XO thanks
>>>> 
>>>> 
>>>> Dan
>>>> 
>>>> 
>>>> _______________________________________________ 
>>>> cryptoparty-chi mailing list 
>>>> cryptoparty-chi at groups.sshchicago.org
>> <mailto:cryptoparty-chi at groups.sshchicago.org>
>>>> http://groups.sshchicago.org/listinfo/cryptoparty-chi
>>> 
>>> _______________________________________________ cryptoparty-chi
>>> mailing list cryptoparty-chi at groups.sshchicago.org
>> <mailto:cryptoparty-chi at groups.sshchicago.org>
>>> http://groups.sshchicago.org/listinfo/cryptoparty-chi
>> 
>> 
>> _______________________________________________ cryptoparty-chi
>> mailing list cryptoparty-chi at groups.sshchicago.org 
>> <mailto:cryptoparty-chi at groups.sshchicago.org> 
>> http://groups.sshchicago.org/listinfo/cryptoparty-chi
>> 
>> 
>> 
>> 
>> _______________________________________________ cryptoparty-chi
>> mailing list cryptoparty-chi at groups.sshchicago.org 
>> http://groups.sshchicago.org/listinfo/cryptoparty-chi
>> 
> 
> 
> 
> _______________________________________________ cryptoparty-chi
> mailing list cryptoparty-chi at groups.sshchicago.org 
> http://groups.sshchicago.org/listinfo/cryptoparty-chi
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJU5612AAoJEPMZXCkqgi71eboQAIg28PrfQnW/RfTjJToDDoHh
vWtJUzRQAnD++hpb8CIECTrfh+l6jKdsy4qxdQGjB/7xEgjlOmtEh883WNBNkmZP
X5TXDPHuuYWad4FSTFGU+vPhazKZtGrkCfQi4RnaHDlYbP5OUjo604FF3V3rhmgv
R6KZzPO9mroHZJI4NZjA7vBZAaJVqBAKa0rFNxmLFnI9BpM0LBJjmrip2o6aONC0
B/HGXKoFRQ36EaI68ufFEPSNbBwqgy1chG+A7EIhuj5vTzIlFuO2LcAfgZ/fUUue
7joBnc2u0wfFx2DHoOWhaAGetgfB+Mvgk6Liw2zrsdLew4M4HKlUlojXPo64e4/s
S1JKy1KgzoXBzEEste4YmtO/LCEYcktEqB8fu36OnapznZNAU1WLVmZ0ROknB0iU
K42f3uEALyvwdoTFxDwl8I2KPZWPnHVzyqwsZFwOb/uB5MALsHGv46eu+VwYu7Dq
pcEoYYldO7iuoziZ8kvkg5ES2QiWIrIEw0gpNfpdX5Chny25KoN3ZQjwLBsllVUf
eArcLUeeDvObFVDe8zTNPkEV8skpqZ86jUE4BHjOD+gq7hEZrP69RhABWkiMpP/K
7VRZ4TfL6qjNnEvzp46fuN3aKk2/xqGG/HLKzAIc2RZ1XTFQxbScDqqit9FbDRzj
7eEjNG5kK9fQGEcqQYDH
=vjkA
-----END PGP SIGNATURE-----