Forgot your password?

Comment: Re:Why so high? (Score 1) 188

by gbjbaanb (#48228591) Attached to: Passwords: Too Much and Not Enough

lol, no. It meant that there was more of a layer between the web server and the DB server than just a php page with the DB credentials in it chmodded to 700.

Assume an attacker has taken over your web server with an exploit and now has full admin access to it. If there is no direct connectivity to the DB, all he can do to get at your DB is call the methods on the middle-tier services that the web server called. These are not "download all passwords" but small and tightly targetted services that only provide a smallpiece of the puzzle that ends up providing the end-user experience.

So, in practice there is nothing the attacker can do to really break your DB. He can attempt to hack the application server, and that is a fair point, but he still has to break it and if you're really doing security the app tier is running a different OS that the web tier, and is firewalled down so only specific ports can be accessed anyway and there are no similar services running on it (such as apache or IIS) that are the usual attack vectors. You also have more leeway in rejecting requests from the webserver that you do not have on the web side of things - whereas a webserver has to respond to anything the user sends to it, you can trust your webserver to only send you specific requests - and if your webserver sends you a mangled request you can rightly assume its been compromised and start to refuse all requests from it (this works best if you have multiple web servers). you raise a big alarm to the admin who can then investigate. Webserver hacks can often go un-noticed if the attacker is careful.

Assume the attacker is really skilled and has hacked your web server *and* your application server... he *still* cannot download all the passwords as they are store in tables that the app tier cannot read, all it can do is fire stored procedure requests at the DB which will only respond with what they were designed for. (none of which allow 'download all passwords')

So you see that while its not impossible to be secure in such an architecture, its damn right difficult for an attacker to really get at your precious data, So difficult they'll either be unable to do it (eg most kiddies with their downloaded apache or IIS hack cookbooks) or will find it so difficult they'll get caught, or they'll just move on to another target.

We used to have a linux web tiier, and a windows middle tier. We encrypted the DB credentials in a web.config and ran the services, each on a different user. The DB sprocs also were allowed access to only those services that required it. I would never encrypt the web tier access to the DB, because I would never allow it. An attacker could take that credential file offline and hack it at his leisure. Its best if he is not given the chance to read it at all. But worse, if he can logon as that user then he can access the DB without even knowing the password. Storing it on the easily-hacked box is the flaw here. Make it hard for them, and assume your webserver is already hacked when you code your site.

As for employees, there's not a lot you can do about that other than monitor their activity on the production server and restrict access. ensure they work in pairs perhaps and maybe (and this is radical for a lot of companies), treat them well so they don't become disgruntled!

Comment: Re:Why are we still using passwords? (Score 2, Insightful) 188

by gbjbaanb (#48226051) Attached to: Passwords: Too Much and Not Enough

Because its wrong.

If you treat each word as a symbol, rather than each letter, then you find the average vocabulary is about 10000 symbols and you have just generated a 4-character password (admittedly in base-10000 rather than base-26) but you'll find its still easily crackable, especially if the hacker uses pre-generated rainbow tables.

Or to put it another way, your xkcd password, if the user has a vocabulary of 10k words, being cracked by a CPU that can manage a trillion hashes per second (easy) means your password can be brute forced in less than 3 hours. For reference, 16 random characters would take 2.5 billion years (ie 64^16 = 8*10^28, which is 8*10^16 trillion seconds, or 2512 million years). Ok probability says your chances are on average half that.. only 1.25 million years.

The best password is a random one, use a tool to generate and store them and let it type them into the password field. If you must use a xkcd style password, at least stick a digit between each word.

Comment: Re:Why so high? (Score 4, Insightful) 188

by gbjbaanb (#48225899) Attached to: Passwords: Too Much and Not Enough

Its not about entering passwords on the web login page, but securing the back-end system so that the password database cannot be stolen.

I am constantly amazed at the reports that hackers have accessed the passwords of every user on some site or other. I used to work at a financial company where the web server didn't have physical connectivity to the DB, every request had to go through a service that was not only secured itself, but also could only run stored procedures which were in turn secured. The net result was that is (or rather when) the web site got hacked, all the hacker could do *at best* was access some public data for a single user, which never included the stored password. (incidentally, the developers didn't have access to production servers either)

So sites like ebay et al have direct DB connectivity to their DBs, so if any hacker exploits some zero day that gives them access to the OS, they can simple "select * from user" and download every password, hashed or not, and crack them at their leisure.

Personally, I think passwords should be stored in plain text in the DB as a reminder to all developers that they need to be protected in other ways so the hacker cannot access them in any circumstance.

However, what I do find strange is that web devs do not know this, I wrote the above for an ArsTechnica comment and the "security editor" promoted a criticism of it where the concept of a 3-tier architecture was "too expensive" an d"inefficient", suggesting that storing your DB credentials in your web code was OK as long as you "secured" it. If this is the level of comprehension of security in the web dev community, then I'm not only unsurprised at the number of hacks, but will be using a randomly-generated password for every website that asks me for a password.

Comment: Re:Options... (Score 3, Insightful) 154

by gbjbaanb (#48202433) Attached to: Ask Slashdot: Aging and Orphan Open Source Projects?

and CodePlex, which although hosted my Microsoft does a better UI job of the overall thing than Google Code (which has dropped support for binary releases, telling you to use dropbox or something instead), and has a pretty poor tracker.

I found github to be a bit 'meh' too in terms of usability, though still better than google code.

I'm not sure what the best one to use is, based on functionality and usability rather than something that has 'git' in the name or some vague "startup coolness". If anyone can enlighten us, I'd appreciate it.

Comment: Re:how pretty (Score 1) 209

by gbjbaanb (#48194139) Attached to: More Eye Candy Coming To Windows 10

I thought they'd turned off all extraneous 'eye candy' to get a slim, lean, 'clean', look that was very efficient... and so I fully expect them to start making some tiles translucent in the next release, and then with shiny graphical highlights too.

Maybe one day they'll make buttons that look like buttons so you know where to click!

Comment: Re:I am not going to convert (Score 1) 243

by gbjbaanb (#48194055) Attached to: Help ESR Stamp Out CVS and SVN In Our Lifetime

You have the same log history in git as you do in Svn - a linear chain of commits. What you describe as a tree is due to the branching and merging. SVN has the same thing, you branch just as much as you do with git, the difference is how the 2 store this information internally.

eg where I work, we use feature branches for independant development. Then the final fixes get merged to the product release branches and trunk. Not too dissimilar from how you tend to use git.

I worked at a place that used git (alas, not me, I was in the Windows team and had to use TFS :( ) and too many people used ot have to call the git guru over because they would munge up their repos. I don't know how they did it, but the fact that they did it too often for my tastes suggests git is a tool that is only for advanced, or experienced users only. Unfortunately that means nowhere near enterprise development.

Today, I'd never suggest git, I'd go with Fossil if I needed a DVCS.

Comment: Re:I am not going to convert (Score 1) 243

by gbjbaanb (#48194029) Attached to: Help ESR Stamp Out CVS and SVN In Our Lifetime

the trouble with DVCSs is there is no repository to backup. Everyone has their copies and a vape in one can (and will) be propagated to the others. Restore your repo from backups and watch as someone then commits the vape when they push their changes to you - the system doesn't know that it shouldn't take that commit.

Its not like a centralized system where you can have proper backups.

Comment: Re:I am not going to convert (Score 1) 243

by gbjbaanb (#48194017) Attached to: Help ESR Stamp Out CVS and SVN In Our Lifetime

you can have a pop at SVN for many things (hell, you can have a pop at anything for the same reasons) but seriously, you're trying to use those arguments?

SVN's security is like all the others, except for servers like VIsualSVN that implement active directory auth. Its not unstable at all, more people complain about it not being more bleeding edge, but of course its job is to be stable. They updated to serf, 3 years ago? and there were issues in the betas. Whoop, what did you expect.

And the 'philosophy' that you cannot ever obliterate history is a good one, one that all other SCMs should follow. If you commit something you shouldn't, it should be a serious thing to remove that history - otherwise everyone will screw your SCM up, and your SCM is the one thing you do not ever want screwed up.

Comment: Re:I am not going to convert (Score 4, Insightful) 243

by gbjbaanb (#48190103) Attached to: Help ESR Stamp Out CVS and SVN In Our Lifetime

Exactly. I don't know why there's such nerdage against SVN except that git is hard, so therefore its better somehow. Despite the fact you can lose your history (irrevocably if you try) and screw things up even if you don't.

If something is working, there's no point in trying to break it. And if you were to go break it, you'd go with Fossil anyway, git done right.

Comment: Re:Some Sense Restored? (Score 1) 519

by gbjbaanb (#48172137) Attached to: Debian Talks About Systemd Once Again

but if Debian drops systemd, what will "automagic" Ubuntu do, seeing as its very much based on Debian?

What it will do is divide the Linux distros into systemd and dependencies, and those without (or with something better). If projects like Gnome become more tied into systemd, will this mean they won't work on non-systemd distros?

Comment: Re:The Middle Class is the Bedrock of Society (Score 2) 838

by gbjbaanb (#48160871) Attached to: Bill Gates: Piketty's Attack on Income Inequality Is Right

Production is essential to the mix here, we tried the concept of simply driving an economy by selling each other non-produced things (typically services, like mortgages and loans) and you saw what happened there around 2007/2008.

An economy cannot be spun out of thin air, we need to sell stuff to each other - sure, but we need to sell stuff we need to buy and make sure its regulated so we don't go into another spiral of 'profits' generated out of our imaginations. After all, my house is worth a million dollars, so I'm incredibly rich.

There is an issue with investment - as you noted. As the rate of return drops due to too much investment money chasing yields, investors demand more interest-bearing investments, which is why housing (as 1 example) has gotten out of control. Instead of investing in productivity, they are simply inflating a bubble (again). This can't be healthy for an economy.

In order to dial out, it is necessary to broaden one's dimension.