This is Good
-
How unique should a password be? I mean if I have a good, strong password, does it matter that it's the same password that someone else has on the system? If we don't know we each have the same password, is that a problem?
I'd guess that for the cryptographically inclined it might make some difference if they can somehow gather information from two accounts having the same password. But I'm not thinking that a developer should enforce password uniqueness.
I saw this article on really unique passwords over at Worsethanfailure.com. It's a bit of a story about someone who worked on an application where the developers enforced unique passwords.
Unique as in I couldn't have the same password as you. Whether we knew about it or not. What's more, the password was used as the foreign key throughout the system, linking tables together. There was a unique constraint on the username as well, but apparently password made a better key for these developers.
Or did it?
This has the ring of urban myth, or of fiction. I can't believe there are developers out there thinking to store passwords unencrypted and then somehow think they make good keys. Even the dullest developer I've worked with wouldn't come up with that one.
And I thought I wouldn't be surprised by something in software.
-
(Enrique asked about referential integrity — if a field was updated, other tables would point to data that didn't exist anymore. "Oh, we had that problem the first time, so we removed all of the foreign key constraints in the database and it works now.")
The relationally impaired developers are very well paid clueless web developers who thinks RDBMS is for data storage one problem now that Algebra and Caculus is native to .NET in LINQ a separate team is needed to teach them how to write Asp.net applications.
Kind regards,
Gift Peddie -
I think it would be a bad idea to enforce unique passwords across all accounts.
If you tell a user that they cannot use a password because it is already in use, then you have told them at least one valid password for a different user. All they have to do then is get a list of valid usernames and try the password against those usernames.
-
You took the words right out of my mouth. I understand that someone might naively think that password uniqueness is some kind of extra security. But telling someone that they can't have the password that they chose because someone else already has it is halfway toward letting them into the system. And given that usernames are probably rarely enrcypted the way passwords are, this approach greatly undermines the system even with encrypted passwords.
If someone knows that they have found at least one good password, and they get hold of the user names (or figure out the username pattern), they may never even need to worry about breaking the password encryption. They can just log in as the person with the matching password and steal data or do whatever damage they can via impersonation. And heaven forbid if that person should happen to have high-level rights. Then the hacker could create their own separate ghost account, forge or erase auditing, etc.
It seems to me that if someone has the same password as someone else, no one should know, unless it is "password" or some other weak password. But in that case, one should already have a password strength policy in place to keep the user from picking the password, but without other users knowing. I don't see password uniqueness as part of a password "strength" policy since it effectively weakens the password protection of the system as a whole.
Even imagining someone thinking naively, though, I don't get the password as a foreign key idea. That doesn't make any sense to me at all.
----
webrunner
-------------------
A SQL query walks into a bar and sees two tables. He walks up to them and asks, "Can I join you?"
Ref.: http://tkyte.blogspot.com/2009/02/sql-joke.html -
The photo reminded me that I regularly got bicycles stolen growing up - not much will stop a thief from cutting a steel lock with an aluminum oxide blade on a circular saw.
Security costs need to be measured. A good password system requires that users can follow it at a reasonable cost. There are many ways to protect businesses from theft - insurance, policies and procedures, legal action. IT tends to treat its role in loss prevention without putting in the context of the entire enterprise.
-
Unique passwords? Imagine how long and how many retries would take to make a new account on Yahoo or Gmail. Why not simply ask the users to remember a GUID? The system can/should be protected by different methods, not something that will make your users/customers to run as the wind.
-
Amen, brother. Too many people out there are good at faking it, and the low-ball language features are only making it easier for them to build faulty systems.
-
Strong passwords are a good thing, but, at the same time, developers should think about what they're doing. A while back, I realized that one of my online passwords that I used every month was completely out of line. I think it was the password for one of my mortgage accounts. I think it was 12 char minimum, needed to be mixed case, could be your last 8 passwords, required both letters and numbers, and they couldn't be grouped together (IE: abc123 bad, ab1c23 ok) and I think required atleast 1 special character (!@#$%^&... etc) There were probably other limitations on the password, but, it was for an account that once logged in couldn't see any identifying information, (not even a partial account number) could only view obsessively privacy protected statements, or pay your bill. paying your bill used a stored account that you couldn't access any of the information on other then the name you gave it to pick from a drop down list... all this security... but insignificant threat if the account was compromised... by comparison, the strictest rule from any other online account I had was "8 chars, letters and numbers" and that includes about 15 banks/creditors, and about 8 other places that handle money.
what's worse, a password so complex that you need to store it, write it down, or have it changed every time you log in, or a password that you might use on a couple other sites that you have an equal amount of trust for?
aaah well... it's all better then a password as a key... but, on the same note, I remember quite a few systems way back when that didn't use a username, just a password, I'm thinking it was for convenience, but... then we grew out of lax security... but, I'm sure some of those systems have since evolved to attempt to be more secure.
and of course, we all have those gem projects in our history that we threw together to solve a temporary problem... the built to retire projects that somehow become a company fixture.
-
Hehe... that brings back memories of logging on to the VAX at school. It only took a password
-
I worked on a VAX for a while back... I guess in the early to mid 90s. maybe that's where I'm remembering the password only to log in...
I didn't have much computer related work history, and was doing basically a data entry job, There were a whole bunch of annoyances with how the system worked, (like the mapping of certain keys in certain situations and the like) I fixed several of those by creating a script to remap keys temporarily.
I think I stepped on IT's toes a bit, I switched the foreground/background color on something on my screen using a login script, and IT got bent out of shape telling me that it took too much processor to reverse the foreground/background on the dumb terminals... I never did figure out if that was the case on a VAX, or if I should report them to thedailywtf, although, I'm inclined to believe they should have been reported.
-
If it was a vector graphic system, then yeah, reversing the background would cause more processor use... maybe. It's highly dependent on the system, and I think most of those were good-old scanning CRTs like you see now (vector systems are pretty rare, 'Asteroids' being the prime example of vector graphics). IT just didn't want you doing any programming, because you might come up with something that everyone would end up using, and they wanted to control that situation, to give the impression that they are the only competent computer people on campus. Sometimes there was a good reason for them to be worried about user programs, but most times I think that was just ego.
-
as near as I could tell, it was a telnet type session. just text going back and forth, and I think either there was a single "reverse" directive, or the reversed letters were actually in the character set.
The other program that acted as a key remap for a certain program however I think did get used. I didn't last very long at that job though. It was at a publishing company that did SEC filings for other companies, their data entry team was worked 12 hours a day 7 days a week. They had a very high turnover. After a few months, I just completely broke down, and after being drug off to the Dr for exhaustion, they told me not to come back... seems they had a zero tolerance policy for sick days.
aaah well, everyone has a few stains on their resume...
-
See, that's not an IT job though. Data entry jobs suck. It's pretty much a manufacturing situation, and the bean counters can keep the operation running fairly efficiently because the job is rote. If you have 1000 data items per day and the average worker can enter 20 per hour, then you need 50 man-hours per day, which is 6.25 8-hour shifts. You can factor in error rates and correction times and you can add some man-hours for QA, and you put your report on the CEO's desk saying you need 8 people every day for 8 hours each, and the guy tells you to do it with 7. That's the way it works for most things, and when that system works, it is a Really Good Thing.
That system is not tolerant of unforseen changes in staffing, and the staff don't have any value as individuals, so if you're not 100% reliable, the system can't tolerate it, and you're out. And it's nothing personal, and they probably even tell you that right to your face, which makes you feel even more worthless.
What a programmer does is an artistic, creative, trial-and-error process, even for the experts... and the bean-counters hate that kind of thing. You can't put a number on every task, for a whole bunch of reasons that make CPA-types really uncomfortable. I can see where they are coming from but they just need to let it go, and look at results. Pay for finished product, which is an economic principle that numbers folks should understand. I have no idea why they don't.
The main issue is that there is no way to tell what's going to be a big project and what's going to be a small one, until you ask the developers and give them enough time to get it about half-way done. The bean counters don't like that concept of having to start on something before you can predict how long it will take and how much it will cost. They want to make cost/benefit analysis of the project, but they can't predict the cost. It is a hard thing to say that something has enough benefit that we're going to do it no matter what the cost is, but with many IT projects that is the case... the thing is needed so badly that it's worth just about any cost to get it done. Obviously you can't have money-grubbing consultants running around with the knowledge that your project is that important, because they will milk you dry.
-
"The main issue is that there is no way to tell what's going to be a big project and what's going to be a small one, until you ask the developers and give them enough time to get it about half-way done. The bean counters don't like that concept of having to start on something before you can predict how long it will take and how much it will cost."
I have to say i disagree with you here. Whilst project managment can become the bain of a developers life ie. when the managment becomes more important than the delivery, it has its place and one of those places is to analyse the costs, timescales and benefits of a project before development has begun. With the correct controls in place each stage of the project can be evaluated and decisions taken as to move on with the project or stop it. I've worked on well managed projects, poorly managed ones and projects that had no management at all; a well managed project is in my experience a joy to work on. More often than not it's down to having a competent, experienced team who can make those difficult early phase decisions such as how much will this cost and how long will this take. If you don't have those people it's going to be tough but that isn't a reason not to try. Without proper controls in place my experience is of tangled messes with costly over-runs and little or no responsibility being taken by anyone.
-
"each stage of the project can be evaluated and decisions taken"
Yes I agree, and that requires the developers to look at the situation, try a few things, do some research or whatever. The point being, you have to ask the developers and they might have to do some work before they can give you an answer. I'm exaggerating with "halfway done" but many times, the analysis of the situation can and should be part of the development process, thus it counts as "working on the project" even if it hasn't been approved yet. There are many ways to screw that up, and I've been on projects where everyone had good intentions and people made reasonable estimates, but they hadn't been allowed to dig into the details enough to realize that their estimates were very wrong and the thing is going to take a lot longer than we thought. I've seen it the other way too, where the project came in way under budget and was done way earlier than anybody thought it could be. The point is, the developers are (usually) not at fault when that happens... it is simply the nature of development. Management needs to realize that even if you pad your budget and schedule, you never know if it's enough padding, particularly if you're making something that has never been made before.
When you sit down to create a bunch of new web pages... that is not the situation. That has been done before, and you can make a pretty good estimate on things like that. If you're writing a new stock market analysis program and using some new math that hasn't been used before... if your project is truly original... then you can't be as correct with your estimate, but you can pull something straight out of your ass if you want to, and that's what most developers do when they are asked to estimate the time for something... they make a wild guess.
I just finished a Windows application for an industry that was, for the most part, not using any software at all. It's an entirely new invention, and it took almost a year to make. My initial estimate was 6 months. However... I stuck by my price, rather than increasing it. I'm going after huge licensing fees here (well, small fee, big audience), and I can eat a bit of start-up cost. It's that 200 bucks a year times 900 users that I'm after, and I'm willing to take a little longer to do it right. This application is financing my new company, and is essentially our flagship product. Other projects we have in the works are also completely new to the world.
Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply