[Crypto-chi] Security Through Obscurity

Fri Feb 20 23:04:50 CST 2015

I think that is a really good point to make Freddy, that when security
through obscurity is the only security it is bad. It is a great
supplement to other security practices though. I know I have changed
which port SSH is running on many times, but only AFTER I have hardened
it with no root logins and using SSH keys.

On Fri, 2015-02-20 at 15:56 -0600, Freddy wrote:
> 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
> > 
> _______________________________________________
> cryptoparty-chi mailing list
> cryptoparty-chi at groups.sshchicago.org
> http://groups.sshchicago.org/listinfo/cryptoparty-chi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://groups.sshchicago.org/pipermail/cryptoparty-chi/attachments/20150220/cc3913e3/attachment.sig>