This post originated from an RSS feed registered with .NET Buzz
by Eric Wise.
Original Post: Of scary security practices
Feed Title: Eric Wise
Feed URL: /error.htm?aspxerrorpath=/blogs/eric.wise/rss.aspx
Feed Description: Business & .NET
Jay had a little mini rant this morning about passwords and security. It's Friday, should be a happy day, so I'm just going to list out some rather absurd security practices I've encountered in my years of consulting and development.
A major (fortune 500) company has an ordering system that in the order table stores the entire credit card number, 3 digit security number, name, expiration date, and billing address. It was all clear text. To top this off their app was vulnerable to injection attacks.
A vendor of time and attendance software and the company I was working for broke off our relationship. Since it was a hosted product we got a SQL server dump of our data. Upon opening the users table all the passwords were in clear text. Upon testing these passwords against people's accounts at work I found that some 85% of people used the same password for their domain login as they did for this application.
A website I was asked to touch up in ASP . NET had a security model that just required a querystring value IsAdmin=true.
Many websites I have worked on have no security on their querystring values whatsoever and just by changing the id number you can get into other user's information.
As John Papa mentioned in comments to Jay's post, I have also encountered many products that run as SA on sql server.
You'll all be happy to know that my ISV product, Easy Assets .NET does the following:
Role based security keeps users out of areas they should not be in.
All passwords are hashed with a random salt
The database user created by the install script only has select rights to the tables and execute rights to the stored procedures I have provided.
At minimum every application you write should have passwords hashed/salted and minimum priviliges on the database account.
Previous Topic
