February 1, 2016 at 9:51 pm
Comments posted to this topic are about the item Maybe Security is Harder than Rocket Science
February 2, 2016 at 12:39 am
Hi Steve,
I take two views on this: on the one hand, for work, we use a password generation program to create and store our server and login passwords. They are almost impossible to remember and I need to look it up when I'm going into a server not normally allowed by my AD login. I make them as long as I can and they are available to all DBAs.
On the other hand, for my day-to-day work, I don't do this. I'm not often at my home computer and others use it too. I prefer the xkcd [1] method because I want to be able to remember the damn things. I often make them as long as the website will allow. I don't share my passwords across websites. To help with the jogging of my memory,
I have hints to help me remember the password. Of course, by writing this, I'm giving information to someone who may wish to compromise me. Not at all a best security practice — to paraphrase Tyler Durden, what is the first rule of your security?
Kind regards,
Sean.
[1] Reviled by Troy Hunt but not at all bad practice for day-to-day work. https://xkcd.com/936/
February 2, 2016 at 5:54 am
What are the best sites for reviewing what kind of security to implement? I don't think I'd send a manager to Stackoverflow.
Is there a good cost modeler?
412-977-3526 call/text
February 2, 2016 at 6:37 am
robert.sterbal 56890 (2/2/2016)
What are the best sites for reviewing what kind of security to implement? I don't think I'd send a manager to Stackoverflow.Is there a good cost modeler?
The News?
In terms of costs - I don't know what you're looking at outside of Europe, but in the UK, we're looking at up to 500, 000 sterling potentially, per breech. Under new European legislation, that changes to up to 2% of an organisation's annual turnover - per breech. This is before costs associated with said breech and reputational harm.
In my experience, dealing with suppliers regarding security - the management very often DO get it, once you get it escalated to the right level. Certainly the management team at my place totally get it and are absolutely on board with making this right. In my experience, it's actually at the technical (and sub-technical) level that you get resistance ... a combination of "can't be bothered with that, don't care, not interested, too difficult, not cool stuff" combined with a belief that restricted privileges at an appropriate level are somehow an insult, belittles them or is somehow - dare I say it, emasculating.
It's not because it's difficult. At heart, it's not - that's just an excuse. It's laziness and poor attitude and often the belief that "I'm a special snowflake and I DESERVE God Mode DAMN IT!" IMO.
I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
February 2, 2016 at 7:11 am
Rocket science always makes me laugh. It's turtles all the way down of course so you can always get more and more detailed. But the basic physics of rocket science is covered in the first term of 2nd year physics where I studied. Almost all physics courses are > rocket science by that metric 🙂 It is the equivalent of saying "It's not spreadsheets".
February 2, 2016 at 7:53 am
My favorite line was, "just stop implementing this yourself."
February 2, 2016 at 8:35 am
robert.sterbal 56890 (2/2/2016)
What are the best sites for reviewing what kind of security to implement? I don't think I'd send a manager to Stackoverflow.Is there a good cost modeler?
100% agree. Steve, you mention that there are some good authentication schemes and some bad. But skip out on telling anyone where to find such a listing.
I think is where SSC could expand. To setup a section about various topics, along with pros, cons. Perhaps let users vote on what they think is the best. Simple standard scripts, complex topics, your authentication topic or other best practices areas. And allow forum discussions specific to that topic.
Would it be difficult? Yes. Would it be beneficial? yes. Would it benefit Redgate? Yes, it would provide them with insight into areas easily addressed with script & code, and where there are areas that need external tools.
The more you are prepared, the less you need it.
February 2, 2016 at 9:21 am
mike.gallamore (2/2/2016)
Rocket science always makes me laugh. It's turtles all the way down of course so you can always get more and more detailed. But the basic physics of rocket science is covered in the first term of 2nd year physics where I studied. Almost all physics courses are > rocket science by that metric 🙂 It is the equivalent of saying "It's not spreadsheets".
Sure, and it's a good title, but these are rocket scientists that don't do the theoretical work. They send the machines up. Maybe rocket engineering?
February 2, 2016 at 9:24 am
Sean Redmond (2/2/2016)
On the other hand, for my day-to-day work, I don't do this. I'm not often at my home computer and others use it too. I prefer the xkcd [1] method because I want to be able to remember the damn things. I often make them as long as the website will allow. I don't share my passwords across websites. To help with the jogging of my memory,
[1] Reviled by Troy Hunt but not at all bad practice for day-to-day work. https://xkcd.com/936/%5B/quote%5D
I use Password Safe (though KeePass, 1Password, etc. are fine) at home. I have the safes for work and home synced through Dropbox, which means I want a very strong password there, but I can access the safes on my phone, work PC, home PC, tablet, etc.
February 2, 2016 at 9:28 am
If you can, use Windows Auth for your apps. No major flaws reported, and it can be secured well.
OAuth is another: http://oauth.net/
If you need to build something else into an app, OWIN in ASP.NET : http://www.asp.net/identity/overview/getting-started/introduction-to-aspnet-identity
If you're using other technologies, there are other frameworks out there. I don't have a comprehensive list, but it's not a bad idea to start one.
February 2, 2016 at 9:29 am
robert.sterbal 56890 (2/2/2016)
What are the best sites for reviewing what kind of security to implement? I don't think I'd send a manager to Stackoverflow.Is there a good cost modeler?
Robert, I'd start here for .NET: https://msdn.microsoft.com/en-us/library/d55zzx87%28v=vs.90%29.aspx
In terms of cost, that's tough. It's very business dependent, and data dependent. The average cost of a breach has been estimated as close to 1mm, but YMMV with your business.
February 2, 2016 at 9:47 am
February 3, 2016 at 4:45 pm
I had an account at a bank that implemented a new online banking system. I had to set a new password. My normal form, especially for banking, the password would be 14 or more characters. Set it, do a couple of things, sign off. Can't get back in again. Call the bank, they reset my account, set the same password, do some stuff, can't get back in again.
Finally talk to someone who knew some of the internals: password had to be 8-12 characters, with no message on the screen about length and no error message if your password was longer.
I very quickly closed my account there.
There was a *nix bug where passwords weren't hashed properly, and regardless of password length, only the first eight characters were stored. So you could type in the first eight, then just randomly pound on the keyboard. A friend of mine installs systems that had that bug: one day at a client site he did just that: entered the key eight characters then just started pounding away on the keyboard while looking away. Said the other people in the room looked at him very strangely.
New tech makes things so much easier: authenticate via AD, enforce strong password policies via AD, make users part of groups and assign said groups access and permissions at the SQL level. When someone leaves the org, suspend or delete the account and you don't have to do a thing at the SQL level. Nice and easy-peasy.
-----
[font="Arial"]Knowledge is of two kinds. We know a subject ourselves or we know where we can find information upon it. --Samuel Johnson[/font]
February 4, 2016 at 8:22 am
The exclusion of special characters mentioned in the editorial is a far too common bad practice. It's sometimes taken to extremes - characters with accents count as special, only letters without any diacritic mark are allowed and only letters from the current English alphabet (so no Þ for example) and passwords are case insensitive, and length must be 6, 7, or 8 characters (fortunately digits are usually allowed as well as letters). So there are only 36 different characters, and a character has an entropy of only 5.391 bits. I imagine the system mentioned in the editorial was case insensitive, giving 62 different characters so an entropy of 5.955 bits per character. Allowing "special" characters (but restricting to a reasonable 8-bit set) gives somewhere between 176 and 252 different characters so per character entropy between 7.457 and 7.958 bits (depending on the definition or "reasonable") but probably very few have keyboard shortcuts set up that allow more than about 155 characters (7.276 bits entropy per character) and don't want characters they can't type in passwords, and most computer-oriented people probably have shorcuts that extend the keybord reachable set to between 120 and 136 characters (so entropy about 7 bits per chatracter). Of course given that many websites will be used from countries with people from countries all over those parts of the world that use some variant of the Roman alphabet, we can expect the number of distinct characters used in passwords to be rather more than might be used by any individual user - for example an Irishman might use "ú" but not "ö", while a German would use the latter but not the former, so attackers not knowing the user's language would have to consider a larger set of charaters than those really available to the user.
Anyway, the meaning of "not reversible" changes as computers get faster. So more entropy per character is a good idea. But even with about 176 different characters I don't want to use passwords with fewer than 16 chracters for anything important, and some of my financial passwords are longer than that.
A long time ago I spent quite a bit of "spare time" effort on designing an adjustable slow hash algorithm because SHA1 was not slow enough to peven preproduction of hash dictionaries, so an attacker who manage to bag the hashed passwords and the seeds would have no difficulty taking over ever user's account. Adjustable because if it was too slow it would mean unacceptable login delay, while if it wasn't too slow now it would probably be too fast the year after next, so the number of rounds of some aspects of the algorith would have to be changed (and the hash recomputed, probably with a new and longer seed as wll as extra rounds) immediately after a user still having his password stored as hashed by last year's version logged in. Unfortunately the collapse of the bursting of the high tech baloon killed that off befoe it was completed. I still think something of that sort will be needed in future, but there were a lot of flaws in the way I was approaching it and when (of if?) someone does it they will have a different approach.
edit: Of course I don't remember passwords like F%$Qv142&szc1c@é|?hogTY^Ýò, I let password safe do it for me.
Tom
February 11, 2016 at 8:11 am
In case anyone hasn't noticed and because Tom mentioned it (although he probably knows himself), SHA-1 is deprecated. Browser support for it is being deprecated. It is considered no longer secure.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 15 posts - 1 through 15 (of 17 total)
You must be logged in to reply to this topic. Login to reply