Best place to encrypt passwords
-
As we all know passwords0 should be encrypted (using an approriate one way algorithm) before they are stored anywhere and when we need to validate a second value against it we should use the same algo to encypt the second value and compare that. My question is where in the architectural model do you believe is the best place to perform this encyption? a) UI Tier b) Business Tier c) Data Tier 0This is applicable to any sensitive data
I have a custom password text box which hashes the password as soon as the user has entered it right in the UI layer, and I pass the hashed password through the application. This ensures that no one can see the original password at all.
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
-
As we all know passwords0 should be encrypted (using an approriate one way algorithm) before they are stored anywhere and when we need to validate a second value against it we should use the same algo to encypt the second value and compare that. My question is where in the architectural model do you believe is the best place to perform this encyption? a) UI Tier b) Business Tier c) Data Tier 0This is applicable to any sensitive data
-
As we all know passwords0 should be encrypted (using an approriate one way algorithm) before they are stored anywhere and when we need to validate a second value against it we should use the same algo to encypt the second value and compare that. My question is where in the architectural model do you believe is the best place to perform this encyption? a) UI Tier b) Business Tier c) Data Tier 0This is applicable to any sensitive data
I don't know if this is frowned upon, but the way I set my last server up was: On the Sql Server instance, I setup a main database, and an ID database. The passwords are entered into the ID database, hashed. Outside of local access, the only access to the ID database was through stored procedures. I used a generic user and password to access the ID database, so a program could send the ID and password entered by the operator, and the stored procedure would do the hash & compare. If there's a match, then a user ID and password to the main database was returned. Again, this ID only has access to stored procedures, and is changed periodically. I'm sure there's a better way to do it, but this meets our needs.
-
I don't know if this is frowned upon, but the way I set my last server up was: On the Sql Server instance, I setup a main database, and an ID database. The passwords are entered into the ID database, hashed. Outside of local access, the only access to the ID database was through stored procedures. I used a generic user and password to access the ID database, so a program could send the ID and password entered by the operator, and the stored procedure would do the hash & compare. If there's a match, then a user ID and password to the main database was returned. Again, this ID only has access to stored procedures, and is changed periodically. I'm sure there's a better way to do it, but this meets our needs.
-
Bert Mitton wrote:
so a program could send the ID and password
That however is a problem. It presumes that the "send" is secure enough. While hashing in the client precludes the need to care.
Good point.
-
I have a custom password text box which hashes the password as soon as the user has entered it right in the UI layer, and I pass the hashed password through the application. This ensures that no one can see the original password at all.
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
This is good - for a website. But what if I have a client that connects over a webservice? Then the control and the entire code for hashing or encrypting are in the client's assembly and can be examined by a potential attacker.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse. -
This is good - for a website. But what if I have a client that connects over a webservice? Then the control and the entire code for hashing or encrypting are in the client's assembly and can be examined by a potential attacker.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse.I don't do websites. I mainly do WPF Desktop Apps , and the hashing is done inside a custom MarkUpExtension. My apps do connect to the DataBase via WCF services, but the client apps are obfuscated and compiled assemblies. Yes, they could probably be easily reverse engineered, and they could perhaps find the hashing algorithms used, but still I don't think it possible to actually reverse any particular password that has been hashed, and this way there is no where in the assembly where the password is not hashed. Personally I don't see any other way of doing it, that is safer. If you have any better ideas, I will love to hear them. :)
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
-
I don't do websites. I mainly do WPF Desktop Apps , and the hashing is done inside a custom MarkUpExtension. My apps do connect to the DataBase via WCF services, but the client apps are obfuscated and compiled assemblies. Yes, they could probably be easily reverse engineered, and they could perhaps find the hashing algorithms used, but still I don't think it possible to actually reverse any particular password that has been hashed, and this way there is no where in the assembly where the password is not hashed. Personally I don't see any other way of doing it, that is safer. If you have any better ideas, I will love to hear them. :)
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
I also prefer clients, that's why I also had to give this some thought. Or, if it has to be a website, I still do the administrative part with a client. But you are right, there is no better solution and securing the webservice is much more important. I would suggest using https and, if you are really paranoid, additional encryption with the help of SOAP extensions.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse. -
I also prefer clients, that's why I also had to give this some thought. Or, if it has to be a website, I still do the administrative part with a client. But you are right, there is no better solution and securing the webservice is much more important. I would suggest using https and, if you are really paranoid, additional encryption with the help of SOAP extensions.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse.CDP1802 wrote:
and securing the webservice is much more important
You hit the nail on the head there.
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
-
CDP1802 wrote:
and securing the webservice is much more important
You hit the nail on the head there.
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
If you look at my question at the top of the page, it is about my private little monster. It spreads over two clients and four webservices and now even has its own XNA UI :)
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse. -
If you look at my question at the top of the page, it is about my private little monster. It spreads over two clients and four webservices and now even has its own XNA UI :)
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse.CDP1802 wrote:
monster
Indeed :-D
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
-
CDP1802 wrote:
monster
Indeed :-D
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
It's my version of a model train :) The goal is to see how far I can go when building it and where my limits are. The fun stuff which my bosses would never allow me to do.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse. -
It's my version of a model train :) The goal is to see how far I can go when building it and where my limits are. The fun stuff which my bosses would never allow me to do.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse.I am lucky enough to work for myself - so I don't have any bosses. Most of my clients couldn't care less about the actual structure of their apps, or what goes into them, they just want to print Invoices and look at pretty graphs of how much money they are making. That gives me the freedom to use the technologies that I like, and I love WPF - it's the dog's danglies as Nagy would say. :laugh:
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
-
I am lucky enough to work for myself - so I don't have any bosses. Most of my clients couldn't care less about the actual structure of their apps, or what goes into them, they just want to print Invoices and look at pretty graphs of how much money they are making. That gives me the freedom to use the technologies that I like, and I love WPF - it's the dog's danglies as Nagy would say. :laugh:
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
WPF is great. But, as you may have guessed, my little project is a game. Webpages are very limited and can make the whole thing just exciting as Excel. Going over to a client and Windows Forms helped a little. We could integrate an XNA window into a control and at least have something moving on the screen. If only the UI was not so ugly... WPF offered a UI with great options for designing, but getting along with XNA (or DirectX) was not easy. This slowly seems to be changing with Silverlight and the Windows Phone 7, but then still it would be two different applications which run at the same time and somehow have to communicate. So, if the prophet does not come to the mountain, I added my own UI to the graphics engine and now am porting the game client to use it. At the moment it is in a very interesting state. It already is far enough to be used seriously, but every step of the way is delayed by graphics bugs, oversights and things I had put off until 'later'. :) My bosses would die instantly when trying to calculate what this evolution has cost, but it's my time and it's hard to put a price tag on the things I have learned :)
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse. -
WPF is great. But, as you may have guessed, my little project is a game. Webpages are very limited and can make the whole thing just exciting as Excel. Going over to a client and Windows Forms helped a little. We could integrate an XNA window into a control and at least have something moving on the screen. If only the UI was not so ugly... WPF offered a UI with great options for designing, but getting along with XNA (or DirectX) was not easy. This slowly seems to be changing with Silverlight and the Windows Phone 7, but then still it would be two different applications which run at the same time and somehow have to communicate. So, if the prophet does not come to the mountain, I added my own UI to the graphics engine and now am porting the game client to use it. At the moment it is in a very interesting state. It already is far enough to be used seriously, but every step of the way is delayed by graphics bugs, oversights and things I had put off until 'later'. :) My bosses would die instantly when trying to calculate what this evolution has cost, but it's my time and it's hard to put a price tag on the things I have learned :)
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse.Sounds like you are really enjoying what you do. Is it a commercial game, or will you release it to the public? My life sounds really boring in comparison. My apps are only complicated by deadlines, otherwise they are just bog standard data applications :-D
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
-
Sounds like you are really enjoying what you do. Is it a commercial game, or will you release it to the public? My life sounds really boring in comparison. My apps are only complicated by deadlines, otherwise they are just bog standard data applications :-D
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
At work it is just as boring for me. If the stuff which bosses or customers want was so much fun, they would probably charge us a fee instead of paying us :) This[^] is an older screenshot of my test program for the graphics engine and the UI. In the picture you can see me blowing up one of my first (and worst) 3D models. I guess, I'm not really talented as an artist. Luckily I found one just last week who is interested in helping. So no, it's not commercial. I work on it in my spare time, but I do intend to install it on a server and offer the client for download. Then we shall see what happens.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse. -
At work it is just as boring for me. If the stuff which bosses or customers want was so much fun, they would probably charge us a fee instead of paying us :) This[^] is an older screenshot of my test program for the graphics engine and the UI. In the picture you can see me blowing up one of my first (and worst) 3D models. I guess, I'm not really talented as an artist. Luckily I found one just last week who is interested in helping. So no, it's not commercial. I work on it in my spare time, but I do intend to install it on a server and offer the client for download. Then we shall see what happens.
And from the clouds a mighty voice spoke:
"Smile and be happy, for it could come worse!"And I smiled and was happy
And it came worse.CDP1802 wrote:
At work it is just as boring for me
Sorry to hear that. :(( I like the controls that you have made for your UI, really cool.:cool: You're character names are nice, especially their friends(James Bond - Walther PPK, Vodka - Q - None) :laugh: You should keep us posted on what is happening with the project.
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
