Roll your own...
-
So, to be brief, our new IT Director thinks he'd rather have us roll our own user authentication functionality, than use the components already present in the ASP.NET Core framework. I recommended strongly against this, but he waved his hand and said, "There won't be any security holes!" I don't intend to pull the eject cord on this job, so I want to ask the public, am I right, or is the IT Director right?
The difficult we do right away... ...the impossible takes slightly longer.
-
So, to be brief, our new IT Director thinks he'd rather have us roll our own user authentication functionality, than use the components already present in the ASP.NET Core framework. I recommended strongly against this, but he waved his hand and said, "There won't be any security holes!" I don't intend to pull the eject cord on this job, so I want to ask the public, am I right, or is the IT Director right?
The difficult we do right away... ...the impossible takes slightly longer.
If it ain't broke don't fix it!
A home without books is a body without soul. Marcus Tullius Cicero PartsBin an Electronics Part Organizer - Release Version 1.4.0 (Many new features) JaxCoder.com Latest Article: EventAggregator
-
So, to be brief, our new IT Director thinks he'd rather have us roll our own user authentication functionality, than use the components already present in the ASP.NET Core framework. I recommended strongly against this, but he waved his hand and said, "There won't be any security holes!" I don't intend to pull the eject cord on this job, so I want to ask the public, am I right, or is the IT Director right?
The difficult we do right away... ...the impossible takes slightly longer.
Forget security holes, what about security compliance and/or 3rd party audits? Depending on your client requirements, the effort needed to confirm compliance may make roll-your-own security a non-starter. For example, you may need to provide an auditing body a copy of your code, and re-submit for every code change that's made, at whatever that cost is to you (or your client) may be prohibitive. Particularly if the auditing body is slow, and you need to get changes out quickly. For security issues, I'd always want to go with a tried-and-true solution, rather than trying to roll my own. I'm not going to try to write my own SSL or AES implementation when there's off the shelf packages that do that. I can have reasonable expectations that 1) they're relative bug free, 2) any bugs or exploits will be addressed in a timely manner and 3) they have an established base of users that give feedback on 1 and 2. Additionally, with roll-your-own, you'll have to dedicate some resources to maintain that portion of your product, which may include maintaining compliance with changing standards. Is your development department deep enough to handle that?
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown
-
So, to be brief, our new IT Director thinks he'd rather have us roll our own user authentication functionality, than use the components already present in the ASP.NET Core framework. I recommended strongly against this, but he waved his hand and said, "There won't be any security holes!" I don't intend to pull the eject cord on this job, so I want to ask the public, am I right, or is the IT Director right?
The difficult we do right away... ...the impossible takes slightly longer.
-
Roll your own by layering it atop the other?
No, not atop the framework. Completely disregarding the framework.
The difficult we do right away... ...the impossible takes slightly longer.
-
Nothing coherent. Just a wave of the hand and being told that I was "only giving theory," as a reason to disregard what I was saying.
The difficult we do right away... ...the impossible takes slightly longer.
-
Forget security holes, what about security compliance and/or 3rd party audits? Depending on your client requirements, the effort needed to confirm compliance may make roll-your-own security a non-starter. For example, you may need to provide an auditing body a copy of your code, and re-submit for every code change that's made, at whatever that cost is to you (or your client) may be prohibitive. Particularly if the auditing body is slow, and you need to get changes out quickly. For security issues, I'd always want to go with a tried-and-true solution, rather than trying to roll my own. I'm not going to try to write my own SSL or AES implementation when there's off the shelf packages that do that. I can have reasonable expectations that 1) they're relative bug free, 2) any bugs or exploits will be addressed in a timely manner and 3) they have an established base of users that give feedback on 1 and 2. Additionally, with roll-your-own, you'll have to dedicate some resources to maintain that portion of your product, which may include maintaining compliance with changing standards. Is your development department deep enough to handle that?
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown
This is a great explanation of other reasons to go with the framework! Our development team consists of me, one other guy and a summer intern. I think we're in trouble.
The difficult we do right away... ...the impossible takes slightly longer.
-
No, not atop the framework. Completely disregarding the framework.
The difficult we do right away... ...the impossible takes slightly longer.
-
So, to be brief, our new IT Director thinks he'd rather have us roll our own user authentication functionality, than use the components already present in the ASP.NET Core framework. I recommended strongly against this, but he waved his hand and said, "There won't be any security holes!" I don't intend to pull the eject cord on this job, so I want to ask the public, am I right, or is the IT Director right?
The difficult we do right away... ...the impossible takes slightly longer.
So he wants to use this gem?
SELECT * FROM Users WHERE UserName=@username AND Password=@password
There's a reason why there are so few secure authentication frameworks. Security is very difficult to get right. No offense to you or your team, but the chances your team is going to come up with something that doesn't have more security holes in it than an established framework is close to zero. Your new Director is showing massive inexperience with a single demand. Where did this person come from and are they still in business?
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles. Dave Kreskowiak
-
Yes, but I mean, layer it atop and say you rolled your own.
I don't follow your clarification.
The difficult we do right away... ...the impossible takes slightly longer.
-
So he wants to use this gem?
SELECT * FROM Users WHERE UserName=@username AND Password=@password
There's a reason why there are so few secure authentication frameworks. Security is very difficult to get right. No offense to you or your team, but the chances your team is going to come up with something that doesn't have more security holes in it than an established framework is close to zero. Your new Director is showing massive inexperience with a single demand. Where did this person come from and are they still in business?
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles. Dave Kreskowiak
Thank you! That's what I thought. Other people in the company have said to me that they think he's a bit of a charlatan. He is a big talker to upper management.
The difficult we do right away... ...the impossible takes slightly longer.
-
So, to be brief, our new IT Director thinks he'd rather have us roll our own user authentication functionality, than use the components already present in the ASP.NET Core framework. I recommended strongly against this, but he waved his hand and said, "There won't be any security holes!" I don't intend to pull the eject cord on this job, so I want to ask the public, am I right, or is the IT Director right?
The difficult we do right away... ...the impossible takes slightly longer.
He sounds like a guy that just BSed his way into his position. There's a time and a place to reinvent the wheel, but security is not something to be taken lightly. I don't use ASP.NET these days, but common sense says Microsoft and their 200 billion dollar budget put more effort into the framework than some company with a director speaking like they're still in teenager land (OMGZ all things suckz except what I like). If he can't articulate a good reason why, that the engineers can appreciate, then he's full of excrement. Besides, a good director should know he's out of touch with some tech and needs to listen to people in the trenches. So, maybe you could convince him if you present your case of why that's a bad idea. But still, my gut reaction says teenager in an adult's body. :laugh: As k5054 mentioned, there are compliance issues (which to be fair the framework may not even handle), testing issues (please don't tell this dude hates unit tests), and issues some may not even think about where a hacker can get your data. Again, I don't use ASP.NET these days, but I do know a hacker can easily bypass encrypted data with a tiny bit of injected script. So, all that encryption means squat if done. Now, there are third party solutions that I wouldn't use for some very valid reasons. But, this isn't that scenario. Granted, I don't use ASP.NET these days so I'm talking out of my arse. But common sense is common sense. If he's so gung ho about it, he should be able to state why.
Jeremy Falcon
-
He sounds like a guy that just BSed his way into his position. There's a time and a place to reinvent the wheel, but security is not something to be taken lightly. I don't use ASP.NET these days, but common sense says Microsoft and their 200 billion dollar budget put more effort into the framework than some company with a director speaking like they're still in teenager land (OMGZ all things suckz except what I like). If he can't articulate a good reason why, that the engineers can appreciate, then he's full of excrement. Besides, a good director should know he's out of touch with some tech and needs to listen to people in the trenches. So, maybe you could convince him if you present your case of why that's a bad idea. But still, my gut reaction says teenager in an adult's body. :laugh: As k5054 mentioned, there are compliance issues (which to be fair the framework may not even handle), testing issues (please don't tell this dude hates unit tests), and issues some may not even think about where a hacker can get your data. Again, I don't use ASP.NET these days, but I do know a hacker can easily bypass encrypted data with a tiny bit of injected script. So, all that encryption means squat if done. Now, there are third party solutions that I wouldn't use for some very valid reasons. But, this isn't that scenario. Granted, I don't use ASP.NET these days so I'm talking out of my arse. But common sense is common sense. If he's so gung ho about it, he should be able to state why.
Jeremy Falcon
It's a little like upside down world because during the discussion, he said he thought that I wasn't backing up my arguments with any substance, "just theory."
The difficult we do right away... ...the impossible takes slightly longer.
-
This is a great explanation of other reasons to go with the framework! Our development team consists of me, one other guy and a summer intern. I think we're in trouble.
The difficult we do right away... ...the impossible takes slightly longer.
May the force be with you, buddy. :laugh:
Jeremy Falcon
-
It's a little like upside down world because during the discussion, he said he thought that I wasn't backing up my arguments with any substance, "just theory."
The difficult we do right away... ...the impossible takes slightly longer.
Assuming the meeting wasn't confrontational, then put together a report that articulates all the reasons why it's a bad idea. If he was a ever an engineer in a previous life and it's was a friendly thing he'll listen. If not, he was never an engineer. Also, it sounds like your dev team is way too small to reinvent the wheel. I'd be surprised if the executives are ok with spinning that kinda money for no gain when there's only 2.5 devs.
Jeremy Falcon
-
I don't follow your clarification.
The difficult we do right away... ...the impossible takes slightly longer.
Like putting a Big Mac in your own wrapper and telling your boss you made it yourself.
-
Assuming the meeting wasn't confrontational, then put together a report that articulates all the reasons why it's a bad idea. If he was a ever an engineer in a previous life and it's was a friendly thing he'll listen. If not, he was never an engineer. Also, it sounds like your dev team is way too small to reinvent the wheel. I'd be surprised if the executives are ok with spinning that kinda money for no gain when there's only 2.5 devs.
Jeremy Falcon
Oh you're so right. Fortunately the higher ups are not going to go all in until we produce a demo program to show what we can do. This puts a serious crimp in our potential output.
The difficult we do right away... ...the impossible takes slightly longer.
-
Thank you! That's what I thought. Other people in the company have said to me that they think he's a bit of a charlatan. He is a big talker to upper management.
The difficult we do right away... ...the impossible takes slightly longer.
When it came to the website that drives my team processes, we just went with Windows Auth. No login page and no user management on our part, and it's about as secure as you can get with minimal effort. HR takes care of the AD accounts and users can request security group membership on their own, and we approve/deny any requests to the groups the site uses. All group memberships are looked at for what you can see/do. If you're not in any groups, you get read-only access to a limited portion of the site. About the only thing we do as far as users is the site allows you to create a user profile where you get to set a bunch of defaults, like landing pages, default view tabs, email notification subscriptions, color theme, font size, and a bunch of other stuff.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles. Dave Kreskowiak
-
Oh you're so right. Fortunately the higher ups are not going to go all in until we produce a demo program to show what we can do. This puts a serious crimp in our potential output.
The difficult we do right away... ...the impossible takes slightly longer.
Oh man, that's a nasty spot to be in.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles. Dave Kreskowiak
-
So, to be brief, our new IT Director thinks he'd rather have us roll our own user authentication functionality, than use the components already present in the ASP.NET Core framework. I recommended strongly against this, but he waved his hand and said, "There won't be any security holes!" I don't intend to pull the eject cord on this job, so I want to ask the public, am I right, or is the IT Director right?
The difficult we do right away... ...the impossible takes slightly longer.
Reinventing the wheel. Maybe a squarish / triangularish kind of wheel.
