Thread: RE: [Rainbowportal-devel] Security
Brought to you by:
danijel_kecman,
manudea
From: Jeffrey M. <je...@my...> - 2005-03-31 18:31:55
|
I agree that this should be added as an option; I would suggest putting an entry in the Web.Config file. I would like to know what advantages there are in a clear text database for passwords? The only one I can think of is sending a user a forgotten password; which in itself is a bad idea from a security point. I beta testing I can see this; that's the one reason I agree to make it an option; the other being I don't want to force anyone into using a feature they don't need or want. I look at this from a damage control security stance; anyone with admin rights (not to mention hackers) can use the Database tool to run a query against the user database and list all the passwords for all the portals; then in turn use this user names and passwords to log in and change content in a very malicious way if they wanted; and the changes would reflex the end users log on info that was stolen; even though the IP address wouldn't; this is little consequence on a corporate web site and could be a major embarrassment at least and financial disaster or worse. I understand that 1.6 will have a better security solution; this was just a hack to hold us over. Jeff Flesher _____ on 31/03/2005 7:44 Jeffrey MRA said the following: I don't like the clear text passwords in the database from a security point; I hope we all can agree on that. I don't want be be a pain, but I hope that encrypted password will be an option, a default option maybe, but still an option. Because having them not encrypted has proven us very usefull in several cases. Rob I suggest adding this function to the Security class; it is the same function used in the Portals Starter Kit which was the successor to IBS Portal. public static string Encrypt(string cleanString) { Byte[] ClearBytes = new UnicodeEncoding().GetBytes(cleanString); Byte[] HashedBytes = ((HashAlgorithm) CryptoConfig.CreateFromName("MD5")).ComputeHash(ClearBytes); return BitConverter.ToString(HashedBytes); } // end Encrypt Call to string EncrptedPassword = Encrypt(password); Such that password will return something like D0-09-1A-0F-E2-B2-09-34-D8-8B-46-06-84-F5-97-89 Much more secure since you can't take this value and log on with it since it is the original password that produces this hash code. Somewhere in the code Add it to the code app_code -> Security -> Security.cs Around line 441 public static string SignOn(string user, string password, bool persistent, string redirectPage) which in turn gets executed in app_code -> Rainbow -> DAL -> UsersDb.cs Around line 994 public Rainbow.Security.User Login(int uid, string password, int portalID) I do realize that we'll have to do a reset password instead of a "I forgot my password" option. Jeff Flesher |
From: Jeffrey M. <je...@my...> - 2005-04-01 02:21:48
|
I don't agree with it being a performance issue; we are talking about one field here; not many users have passwords with more than 10 characters; what are we talking about is microseconds of computer CPU time. There is no software to install with the function I included; nor is there a reason to use or offer to use more than one option for encryption; overkill. As far as changing the database; it is not need; check to see if the password is in clear text; if so use it; if not then use the encryption method; keep it simple (KISS). This is not rocket science it's the ability to encrypt passwords to make a secure or more secure system. I will also disagree as that sending password reminder is a good thing; it's not; in fact it is a serious security birch; at least with a password reset you can add a traceable element to the transaction; keep in mind if someone stills your email and than ask for a password and as is you just hand it out; this happens all the time; I know that not to long ago someone here had their email stolen; now what if they used it to hack his web site? I believe fully in security and all I'm suggesting is the bare minimum; but your right; we need to explore all options and let everyone let there option known; I value your option but I ask you to error on the side of good judgment; in other words come up with a good argument. Ask yourself what you think a customer wants; as programmers we some things get myopic and can't see the obvious; if this is an e-commerce site (and I think it is or can be) then where is the security? I can come up with far too many arguments for security and none for not having any; that's just my option and all most 30 years as a computer programmer. Jeff Flesher -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jonathan Minond Sent: Thursday, March 31, 2005 2:24 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security Would that not require end users to install extra things beyond a browser? Like an email client with that supports is, or some way to manage the key? Seems like it gets complicated. Maybe something to consider as one of the options for 1.6. We can technically offer sever options, that are Site or Portal admin defined. As a default for the application I wouldn't suggest it. I suggest default is simple hash with a new password generator. Then a user can log in and edit their profile and password again. Why don't we get a list of the options? And then maybe we can start looking at how to handle this. We also don't want to go to crazy... letting people have so many options. I think standard are Clear text MD5 SHA128 SHA256 SHA512 Etc... Anything over 256 is already costing a lot performance wise, but I suppose if you want to potentially have rainbow support enterprise, and economic type systems you need to offer high end... I don't think any of this is a rush decisions, but we should get a list of options that people agree rb should support. My opinion is that we should not force end users to rely much on extra things beyond the browser as far as core features are concerned. - Jonathan -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Pekka Ylenius Sent: Thursday, March 31, 2005 10:34 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security How about 2way encryption... It is possible to return password but it is not clear text. -----Original Message----- From: "Jonathan Minond" <jon...@jo...> To: <rai...@li...> Date: Thu, 31 Mar 2005 21:16:29 +0200 Subject: RE: [Rainbowportal-devel] Security > Clear text offeres > > 1) password remindes > > 2) Less security = more performance > > > > The more you hash and secure things, the slower they will be. however > this > is not sucha worry for just logins. > > And instead of password reminder you can offer a "Generate new > password" > feature. > > > > The problem with just implementing this into 1.5.. its no so > straightforward, you need to fix data for existing passwords as well. > > > > - Jonathan ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel |
From: Jonathan M. <jon...@jo...> - 2005-04-01 06:27:28
|
So we agreed that default should be hashed :-) Not arguing..... From what I understand in your mail, there is no password reminder... which I also agreed with, but it seems you say new password generator is also no good. So what do you want to do if a legitimate user looses there password? What would be required for the two way encryption route you mentioned? How do you accomplish this with only a browser? -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jeffrey MRA Sent: Friday, April 01, 2005 4:21 AM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security I don't agree with it being a performance issue; we are talking about one field here; not many users have passwords with more than 10 characters; what are we talking about is microseconds of computer CPU time. There is no software to install with the function I included; nor is there a reason to use or offer to use more than one option for encryption; overkill. As far as changing the database; it is not need; check to see if the password is in clear text; if so use it; if not then use the encryption method; keep it simple (KISS). This is not rocket science it's the ability to encrypt passwords to make a secure or more secure system. I will also disagree as that sending password reminder is a good thing; it's not; in fact it is a serious security birch; at least with a password reset you can add a traceable element to the transaction; keep in mind if someone stills your email and than ask for a password and as is you just hand it out; this happens all the time; I know that not to long ago someone here had their email stolen; now what if they used it to hack his web site? I believe fully in security and all I'm suggesting is the bare minimum; but your right; we need to explore all options and let everyone let there option known; I value your option but I ask you to error on the side of good judgment; in other words come up with a good argument. Ask yourself what you think a customer wants; as programmers we some things get myopic and can't see the obvious; if this is an e-commerce site (and I think it is or can be) then where is the security? I can come up with far too many arguments for security and none for not having any; that's just my option and all most 30 years as a computer programmer. Jeff Flesher -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jonathan Minond Sent: Thursday, March 31, 2005 2:24 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security Would that not require end users to install extra things beyond a browser? Like an email client with that supports is, or some way to manage the key? Seems like it gets complicated. Maybe something to consider as one of the options for 1.6. We can technically offer sever options, that are Site or Portal admin defined. As a default for the application I wouldn't suggest it. I suggest default is simple hash with a new password generator. Then a user can log in and edit their profile and password again. Why don't we get a list of the options? And then maybe we can start looking at how to handle this. We also don't want to go to crazy... letting people have so many options. I think standard are Clear text MD5 SHA128 SHA256 SHA512 Etc... Anything over 256 is already costing a lot performance wise, but I suppose if you want to potentially have rainbow support enterprise, and economic type systems you need to offer high end... I don't think any of this is a rush decisions, but we should get a list of options that people agree rb should support. My opinion is that we should not force end users to rely much on extra things beyond the browser as far as core features are concerned. - Jonathan -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Pekka Ylenius Sent: Thursday, March 31, 2005 10:34 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security How about 2way encryption... It is possible to return password but it is not clear text. -----Original Message----- From: "Jonathan Minond" <jon...@jo...> To: <rai...@li...> Date: Thu, 31 Mar 2005 21:16:29 +0200 Subject: RE: [Rainbowportal-devel] Security > Clear text offeres > > 1) password remindes > > 2) Less security = more performance > > > > The more you hash and secure things, the slower they will be. however > this > is not sucha worry for just logins. > > And instead of password reminder you can offer a "Generate new > password" > feature. > > > > The problem with just implementing this into 1.5.. its no so > straightforward, you need to fix data for existing passwords as well. > > > > - Jonathan ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel |
From: Jonathan M. <jon...@jo...> - 2005-04-01 06:31:22
|
Also... One of the plans in 1.6 is that almost everything is encryptable, Meaning you can encrypt all your data from content not just passwords :-) But this is all server side so far.... Can you provide some links on acceptable 2 way hash solutions? -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jeffrey MRA Sent: Friday, April 01, 2005 4:21 AM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security I don't agree with it being a performance issue; we are talking about one field here; not many users have passwords with more than 10 characters; what are we talking about is microseconds of computer CPU time. There is no software to install with the function I included; nor is there a reason to use or offer to use more than one option for encryption; overkill. As far as changing the database; it is not need; check to see if the password is in clear text; if so use it; if not then use the encryption method; keep it simple (KISS). This is not rocket science it's the ability to encrypt passwords to make a secure or more secure system. I will also disagree as that sending password reminder is a good thing; it's not; in fact it is a serious security birch; at least with a password reset you can add a traceable element to the transaction; keep in mind if someone stills your email and than ask for a password and as is you just hand it out; this happens all the time; I know that not to long ago someone here had their email stolen; now what if they used it to hack his web site? I believe fully in security and all I'm suggesting is the bare minimum; but your right; we need to explore all options and let everyone let there option known; I value your option but I ask you to error on the side of good judgment; in other words come up with a good argument. Ask yourself what you think a customer wants; as programmers we some things get myopic and can't see the obvious; if this is an e-commerce site (and I think it is or can be) then where is the security? I can come up with far too many arguments for security and none for not having any; that's just my option and all most 30 years as a computer programmer. Jeff Flesher -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jonathan Minond Sent: Thursday, March 31, 2005 2:24 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security Would that not require end users to install extra things beyond a browser? Like an email client with that supports is, or some way to manage the key? Seems like it gets complicated. Maybe something to consider as one of the options for 1.6. We can technically offer sever options, that are Site or Portal admin defined. As a default for the application I wouldn't suggest it. I suggest default is simple hash with a new password generator. Then a user can log in and edit their profile and password again. Why don't we get a list of the options? And then maybe we can start looking at how to handle this. We also don't want to go to crazy... letting people have so many options. I think standard are Clear text MD5 SHA128 SHA256 SHA512 Etc... Anything over 256 is already costing a lot performance wise, but I suppose if you want to potentially have rainbow support enterprise, and economic type systems you need to offer high end... I don't think any of this is a rush decisions, but we should get a list of options that people agree rb should support. My opinion is that we should not force end users to rely much on extra things beyond the browser as far as core features are concerned. - Jonathan -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Pekka Ylenius Sent: Thursday, March 31, 2005 10:34 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security How about 2way encryption... It is possible to return password but it is not clear text. -----Original Message----- From: "Jonathan Minond" <jon...@jo...> To: <rai...@li...> Date: Thu, 31 Mar 2005 21:16:29 +0200 Subject: RE: [Rainbowportal-devel] Security > Clear text offeres > > 1) password remindes > > 2) Less security = more performance > > > > The more you hash and secure things, the slower they will be. however > this > is not sucha worry for just logins. > > And instead of password reminder you can offer a "Generate new > password" > feature. > > > > The problem with just implementing this into 1.5.. its no so > straightforward, you need to fix data for existing passwords as well. > > > > - Jonathan ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel |
From: Jeffrey M. <je...@my...> - 2005-04-01 07:12:43
|
I like the reset password idea; you use a password generator when you don't care about security is the bottom line; this is the 10 dollar question; how secure is that; you are going to give them new passwords why not give them the old one? Keep in mind some people who don't know anything about security use email addresses as user ID's thus all a hacker has to guess is the password; and what's worse is they use the same password for all web sites; and the same email address; wow; you mean I could hack into other sites with their credentials for this site? I'm sure that the banks don't use email address as User ID's anymore but think of all the sites that do; need I say more about this; far too easy; even Passport uses this flaw in security; so how secure is any security? You have to make it simple and you don't want to break existing code so you have to plan this out. I don't know what the 1.6 plan is nor do I know when it will release; if we are waiting for ASP 2.0 and to use its new way of dealing with security then we have to ask our self how much time and effort do we want to put into this; so far all you have to do is cut and paste and add a few lines to see if the database is stored in clear text or it has a hash value in it; then make the new forgot password screen; in a secure site you would use a three key system; public, private and fixed; public is the password that you use to log on to the site; this is not by definition as much as it is someone looking over your back; private is a password hint; this is also a hashed value in the database but it uses your fixed key to decrypt it; this fixed key should be different for each portal and you can not change it without rehashing your whole database. Now you send them a link to the reset page where they enter their User ID (lets hope we can someday get away from using email addresses) and then their hint; you then hash it out and if it's correct you allow them to enter their new password if not then you check their last log on IP address range with the current one and calculate the risk factor; if the security risk factor is low enough you could do several things like ask them for other information in their profile and at some point you have to answer the 10 dollar question how secure is this and now what do we do. Security for the most part is a false sense of security at best; but as programmers we have to do our part to make it as secure as possible for the sake of our customer or even ourselves. I know a lot about security; I retired from the Military where I use to work on top secret computer and electronic equipment; I know more about security then most people want to know; once I retired I went to work for the EPA and BLM as a computer program also; and I learned that they don't hold my high standard for security like the Air Force did; so this was my compromise; and let me tell you that you never want to compromise security as much as you do now; in fact you have no security only a prayer that know one knows how bad your security is but you; if your customer found out they would not be doing business with you for long. Too much said? Not enough if you ask me. By the way anyone using the new resource files I posted at http://www.binarybit.net/site/160/default.aspx? Jeff Flesher -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jonathan Minond Sent: Thursday, March 31, 2005 11:27 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security So we agreed that default should be hashed :-) Not arguing..... From what I understand in your mail, there is no password reminder... which I also agreed with, but it seems you say new password generator is also no good. So what do you want to do if a legitimate user looses there password? What would be required for the two way encryption route you mentioned? How do you accomplish this with only a browser? -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jeffrey MRA Sent: Friday, April 01, 2005 4:21 AM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security I don't agree with it being a performance issue; we are talking about one field here; not many users have passwords with more than 10 characters; what are we talking about is microseconds of computer CPU time. There is no software to install with the function I included; nor is there a reason to use or offer to use more than one option for encryption; overkill. As far as changing the database; it is not need; check to see if the password is in clear text; if so use it; if not then use the encryption method; keep it simple (KISS). This is not rocket science it's the ability to encrypt passwords to make a secure or more secure system. I will also disagree as that sending password reminder is a good thing; it's not; in fact it is a serious security birch; at least with a password reset you can add a traceable element to the transaction; keep in mind if someone stills your email and than ask for a password and as is you just hand it out; this happens all the time; I know that not to long ago someone here had their email stolen; now what if they used it to hack his web site? I believe fully in security and all I'm suggesting is the bare minimum; but your right; we need to explore all options and let everyone let there option known; I value your option but I ask you to error on the side of good judgment; in other words come up with a good argument. Ask yourself what you think a customer wants; as programmers we some things get myopic and can't see the obvious; if this is an e-commerce site (and I think it is or can be) then where is the security? I can come up with far too many arguments for security and none for not having any; that's just my option and all most 30 years as a computer programmer. Jeff Flesher -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jonathan Minond Sent: Thursday, March 31, 2005 2:24 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security Would that not require end users to install extra things beyond a browser? Like an email client with that supports is, or some way to manage the key? Seems like it gets complicated. Maybe something to consider as one of the options for 1.6. We can technically offer sever options, that are Site or Portal admin defined. As a default for the application I wouldn't suggest it. I suggest default is simple hash with a new password generator. Then a user can log in and edit their profile and password again. Why don't we get a list of the options? And then maybe we can start looking at how to handle this. We also don't want to go to crazy... letting people have so many options. I think standard are Clear text MD5 SHA128 SHA256 SHA512 Etc... Anything over 256 is already costing a lot performance wise, but I suppose if you want to potentially have rainbow support enterprise, and economic type systems you need to offer high end... I don't think any of this is a rush decisions, but we should get a list of options that people agree rb should support. My opinion is that we should not force end users to rely much on extra things beyond the browser as far as core features are concerned. - Jonathan -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Pekka Ylenius Sent: Thursday, March 31, 2005 10:34 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security How about 2way encryption... It is possible to return password but it is not clear text. -----Original Message----- From: "Jonathan Minond" <jon...@jo...> To: <rai...@li...> Date: Thu, 31 Mar 2005 21:16:29 +0200 Subject: RE: [Rainbowportal-devel] Security > Clear text offeres > > 1) password remindes > > 2) Less security = more performance > > > > The more you hash and secure things, the slower they will be. however > this > is not sucha worry for just logins. > > And instead of password reminder you can offer a "Generate new > password" > feature. > > > > The problem with just implementing this into 1.5.. its no so > straightforward, you need to fix data for existing passwords as well. > > > > - Jonathan ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel |
From: Jonathan M. <jon...@jo...> - 2005-04-01 07:26:19
|
1) I downloaded the resource files, haven't really tested them yet, still on the page manager :-) I didn't see Hebrew (He) there though, maybe I missed it.. I will arrange sometime this week for a full translation of the English to Hebrew and get it to you next week. 2) I think we all agree that security is nessesary. What I got a little confused on here is is this something you want now in 1.5 in the current cvs? Or is this something you are making sure is dealt with correctly in 1.6? If its more for 1.6, it seems like you have a good idea on the feature set and options going all the way through on the matter figured out. Maybe you would like to get an organized page on the matter open in the confluence so we can start to get a "Security Spec" for 1.6 as far as passwords and user security. Even go as far as taking it to a few areas... specing what needs to be stored on db... specing end user features like the questions, drill down... also take into account login through web services.. where the login is not coming directly from the main site, but possibly a client rss reader, or other means. -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jeffrey MRA Sent: Friday, April 01, 2005 9:12 AM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security I like the reset password idea; you use a password generator when you don't care about security is the bottom line; this is the 10 dollar question; how secure is that; you are going to give them new passwords why not give them the old one? Keep in mind some people who don't know anything about security use email addresses as user ID's thus all a hacker has to guess is the password; and what's worse is they use the same password for all web sites; and the same email address; wow; you mean I could hack into other sites with their credentials for this site? I'm sure that the banks don't use email address as User ID's anymore but think of all the sites that do; need I say more about this; far too easy; even Passport uses this flaw in security; so how secure is any security? You have to make it simple and you don't want to break existing code so you have to plan this out. I don't know what the 1.6 plan is nor do I know when it will release; if we are waiting for ASP 2.0 and to use its new way of dealing with security then we have to ask our self how much time and effort do we want to put into this; so far all you have to do is cut and paste and add a few lines to see if the database is stored in clear text or it has a hash value in it; then make the new forgot password screen; in a secure site you would use a three key system; public, private and fixed; public is the password that you use to log on to the site; this is not by definition as much as it is someone looking over your back; private is a password hint; this is also a hashed value in the database but it uses your fixed key to decrypt it; this fixed key should be different for each portal and you can not change it without rehashing your whole database. Now you send them a link to the reset page where they enter their User ID (lets hope we can someday get away from using email addresses) and then their hint; you then hash it out and if it's correct you allow them to enter their new password if not then you check their last log on IP address range with the current one and calculate the risk factor; if the security risk factor is low enough you could do several things like ask them for other information in their profile and at some point you have to answer the 10 dollar question how secure is this and now what do we do. Security for the most part is a false sense of security at best; but as programmers we have to do our part to make it as secure as possible for the sake of our customer or even ourselves. I know a lot about security; I retired from the Military where I use to work on top secret computer and electronic equipment; I know more about security then most people want to know; once I retired I went to work for the EPA and BLM as a computer program also; and I learned that they don't hold my high standard for security like the Air Force did; so this was my compromise; and let me tell you that you never want to compromise security as much as you do now; in fact you have no security only a prayer that know one knows how bad your security is but you; if your customer found out they would not be doing business with you for long. Too much said? Not enough if you ask me. By the way anyone using the new resource files I posted at http://www.binarybit.net/site/160/default.aspx? Jeff Flesher -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jonathan Minond Sent: Thursday, March 31, 2005 11:27 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security So we agreed that default should be hashed :-) Not arguing..... From what I understand in your mail, there is no password reminder... which I also agreed with, but it seems you say new password generator is also no good. So what do you want to do if a legitimate user looses there password? What would be required for the two way encryption route you mentioned? How do you accomplish this with only a browser? -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jeffrey MRA Sent: Friday, April 01, 2005 4:21 AM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security I don't agree with it being a performance issue; we are talking about one field here; not many users have passwords with more than 10 characters; what are we talking about is microseconds of computer CPU time. There is no software to install with the function I included; nor is there a reason to use or offer to use more than one option for encryption; overkill. As far as changing the database; it is not need; check to see if the password is in clear text; if so use it; if not then use the encryption method; keep it simple (KISS). This is not rocket science it's the ability to encrypt passwords to make a secure or more secure system. I will also disagree as that sending password reminder is a good thing; it's not; in fact it is a serious security birch; at least with a password reset you can add a traceable element to the transaction; keep in mind if someone stills your email and than ask for a password and as is you just hand it out; this happens all the time; I know that not to long ago someone here had their email stolen; now what if they used it to hack his web site? I believe fully in security and all I'm suggesting is the bare minimum; but your right; we need to explore all options and let everyone let there option known; I value your option but I ask you to error on the side of good judgment; in other words come up with a good argument. Ask yourself what you think a customer wants; as programmers we some things get myopic and can't see the obvious; if this is an e-commerce site (and I think it is or can be) then where is the security? I can come up with far too many arguments for security and none for not having any; that's just my option and all most 30 years as a computer programmer. Jeff Flesher -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jonathan Minond Sent: Thursday, March 31, 2005 2:24 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security Would that not require end users to install extra things beyond a browser? Like an email client with that supports is, or some way to manage the key? Seems like it gets complicated. Maybe something to consider as one of the options for 1.6. We can technically offer sever options, that are Site or Portal admin defined. As a default for the application I wouldn't suggest it. I suggest default is simple hash with a new password generator. Then a user can log in and edit their profile and password again. Why don't we get a list of the options? And then maybe we can start looking at how to handle this. We also don't want to go to crazy... letting people have so many options. I think standard are Clear text MD5 SHA128 SHA256 SHA512 Etc... Anything over 256 is already costing a lot performance wise, but I suppose if you want to potentially have rainbow support enterprise, and economic type systems you need to offer high end... I don't think any of this is a rush decisions, but we should get a list of options that people agree rb should support. My opinion is that we should not force end users to rely much on extra things beyond the browser as far as core features are concerned. - Jonathan -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Pekka Ylenius Sent: Thursday, March 31, 2005 10:34 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security How about 2way encryption... It is possible to return password but it is not clear text. -----Original Message----- From: "Jonathan Minond" <jon...@jo...> To: <rai...@li...> Date: Thu, 31 Mar 2005 21:16:29 +0200 Subject: RE: [Rainbowportal-devel] Security > Clear text offeres > > 1) password remindes > > 2) Less security = more performance > > > > The more you hash and secure things, the slower they will be. however > this > is not sucha worry for just logins. > > And instead of password reminder you can offer a "Generate new > password" > feature. > > > > The problem with just implementing this into 1.5.. its no so > straightforward, you need to fix data for existing passwords as well. > > > > - Jonathan ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel |
From: Jeffrey M. <je...@my...> - 2005-04-01 07:49:31
|
Read my last reply before this one please. ASP 2.0 has some very good features; are we talking about using any of them or making new ones? I'd opted to roll my own if security is really and issue and if you are going to spend a lot of CPU time then it better be. Now I have to look at two cases here so for argument sakes I'm going to assume that we talking about 1.6 and ASP 2.0 and make one rule; that this is going to be a secure communication as we can for the effort; CPU time is a premium it can make or break your site; load factors and farming all factor in; I have an ideal solution I have used for years and it will work even better with ASP 2.0; Windows Applications... What this is a web site you say; ASP 2.0 makes Window apps live update feature so easy web sites my become posse; you simple write a Windows app to use your SQL server and then all your CPU time is on the client end and the encryption isn't done via a browser at all but in the Windows Application; this runs in Mono LAN so Linux users can breath again; even MAC will be able to run these new C# Window apps; in fact you can do the whole web site in a Windows app. Now the second case: Encryption of large amounts of data is time consuming; keep in mind there are many ways to do this; I still like the three key system; but with a twist from the last one I described; public is given to all authorized users; private is the users log on password and fixed is again for the portal. Client side decryption can be done using C# or JAVA script (Limited) or signed JAVA classes (Expensive and Limited); I would use C# even though you might limit your target base; always a trade off. Hash is out of the question for data content; TripleDES or Rijndael are both good; the first is faster from my test but the second more secure. You hash the three keys together to make a password for the following. public static void Encrypt(string fileIn, string fileOut, string password) { if (password == null) return; if (password.Trim().Length == 0) return; // First we are going to open the file streams FileStream FileStreamIn = new FileStream(fileIn, FileMode.Open, FileAccess.Read); FileStream FileStreamOut = new FileStream(fileOut, FileMode.OpenOrCreate, FileAccess.Write); // Then we are going to derive a Key and // an IV from the Password and create an algorithm PasswordDeriveBytes ThisPasswordDeriveByte = new PasswordDeriveBytes(password, new byte[] {0x49, 0x76, 0x61, 0x6e, 0x20, 0x4d, 0x65, 0x64, 0x76, 0x65, 0x64, 0x65, 0x76}); #if (UseTripleDES) TripleDES CryptoAlgorithm = TripleDES.Create(); CryptoAlgorithm.Key = ThisPasswordDeriveByte.GetBytes(16); CryptoAlgorithm.IV = ThisPasswordDeriveByte.GetBytes(8); #endif #if (UseRijndael) Rijndael CryptoAlgorithm = Rijndael.Create(); CryptoAlgorithm.Key = ThisPasswordDeriveByte.GetBytes(32); CryptoAlgorithm.IV = ThisPasswordDeriveByte.GetBytes(16); #endif // Now create a crypto stream through which we are going to be pumping data. // Our fileOut is going to be receiving the encrypted bytes. CryptoStream ThisCryptoStream = new CryptoStream(FileStreamOut, CryptoAlgorithm.CreateEncryptor(), CryptoStreamMode.Write); // Now will will initialize a Buffer // and will be processing the input file in chunks. // This is done to avoid reading the whole file // (which can be huge) into memory. int BufferLen = 4096; byte[] Buffer = new byte[BufferLen]; int BytesRead; do { // read a chunk of data from the input file BytesRead = FileStreamIn.Read(Buffer, 0, BufferLen); // encrypt it ThisCryptoStream.Write(Buffer, 0, BytesRead); } while(BytesRead != 0); // close everything // this will also close the unrelying FileStreamOut stream ThisCryptoStream.Close(); FileStreamIn.Close(); } public static void Decrypt(string fileIn, string fileOut, string password) { if (password == null) return; if (password.Trim().Length == 0) return; // First we are going to open the file streams FileStream FileStreamIn = new FileStream(fileIn, FileMode.Open, FileAccess.Read); FileStream FileStreamOut = new FileStream(fileOut, FileMode.OpenOrCreate, FileAccess.Write); // Then we are going to derive a Key and // an IV from the Password and create an algorithm PasswordDeriveBytes ThisPasswordDeriveByte = new PasswordDeriveBytes(password, new byte[] {0x49, 0x76, 0x61, 0x6e, 0x20, 0x4d, 0x65, 0x64, 0x76, 0x65, 0x64, 0x65, 0x76}); #if (UseTripleDES) TripleDES CryptoAlgorithm = TripleDES.Create(); CryptoAlgorithm.Key = ThisPasswordDeriveByte.GetBytes(16); CryptoAlgorithm.IV = ThisPasswordDeriveByte.GetBytes(8); #endif #if (UseRijndael) Rijndael CryptoAlgorithm = Rijndael.Create(); CryptoAlgorithm.Key = ThisPasswordDeriveByte.GetBytes(32); CryptoAlgorithm.IV = ThisPasswordDeriveByte.GetBytes(16); #endif // Now create a crypto stream through which we are going to be pumping data. // Our fileOut is going to be receiving the Decrypted bytes. CryptoStream ThisCryptoStream = new CryptoStream(FileStreamOut, CryptoAlgorithm.CreateDecryptor(), CryptoStreamMode.Write); // Now will will initialize a Buffer // and will be processing the input file in chunks. // This is done to avoid reading the // whole file (which can be huge) into memory. int BufferLen = 4096; byte[] Buffer = new byte[BufferLen]; int BytesRead; do { // read a chunk of data from the input file BytesRead = FileStreamIn.Read(Buffer, 0, BufferLen); // Decrypt it ThisCryptoStream.Write(Buffer, 0, BytesRead); } while(BytesRead != 0); // close everything ThisCryptoStream.Close(); // this will also close the unrelying FileStreamOut stream FileStreamIn.Close(); } I never tried this in a client code; but if C# code truly can run client side this should work; by the way these are very good functions I hope you enjoy them as much as I did. As far as links go a search engine would drive me crazy answering a question I already know; I could find worse sources of info and some might think better; but I say if it works good use it; it's simple and proven the key is in the keys; three keys: public, private and fixed; how much more secure to do need it? Jeff Flesher -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jonathan Minond Sent: Thursday, March 31, 2005 11:31 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security Also... One of the plans in 1.6 is that almost everything is encryptable, Meaning you can encrypt all your data from content not just passwords :-) But this is all server side so far.... Can you provide some links on acceptable 2 way hash solutions? -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jeffrey MRA Sent: Friday, April 01, 2005 4:21 AM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security I don't agree with it being a performance issue; we are talking about one field here; not many users have passwords with more than 10 characters; what are we talking about is microseconds of computer CPU time. There is no software to install with the function I included; nor is there a reason to use or offer to use more than one option for encryption; overkill. As far as changing the database; it is not need; check to see if the password is in clear text; if so use it; if not then use the encryption method; keep it simple (KISS). This is not rocket science it's the ability to encrypt passwords to make a secure or more secure system. I will also disagree as that sending password reminder is a good thing; it's not; in fact it is a serious security birch; at least with a password reset you can add a traceable element to the transaction; keep in mind if someone stills your email and than ask for a password and as is you just hand it out; this happens all the time; I know that not to long ago someone here had their email stolen; now what if they used it to hack his web site? I believe fully in security and all I'm suggesting is the bare minimum; but your right; we need to explore all options and let everyone let there option known; I value your option but I ask you to error on the side of good judgment; in other words come up with a good argument. Ask yourself what you think a customer wants; as programmers we some things get myopic and can't see the obvious; if this is an e-commerce site (and I think it is or can be) then where is the security? I can come up with far too many arguments for security and none for not having any; that's just my option and all most 30 years as a computer programmer. Jeff Flesher -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jonathan Minond Sent: Thursday, March 31, 2005 2:24 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security Would that not require end users to install extra things beyond a browser? Like an email client with that supports is, or some way to manage the key? Seems like it gets complicated. Maybe something to consider as one of the options for 1.6. We can technically offer sever options, that are Site or Portal admin defined. As a default for the application I wouldn't suggest it. I suggest default is simple hash with a new password generator. Then a user can log in and edit their profile and password again. Why don't we get a list of the options? And then maybe we can start looking at how to handle this. We also don't want to go to crazy... letting people have so many options. I think standard are Clear text MD5 SHA128 SHA256 SHA512 Etc... Anything over 256 is already costing a lot performance wise, but I suppose if you want to potentially have rainbow support enterprise, and economic type systems you need to offer high end... I don't think any of this is a rush decisions, but we should get a list of options that people agree rb should support. My opinion is that we should not force end users to rely much on extra things beyond the browser as far as core features are concerned. - Jonathan -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Pekka Ylenius Sent: Thursday, March 31, 2005 10:34 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security How about 2way encryption... It is possible to return password but it is not clear text. -----Original Message----- From: "Jonathan Minond" <jon...@jo...> To: <rai...@li...> Date: Thu, 31 Mar 2005 21:16:29 +0200 Subject: RE: [Rainbowportal-devel] Security > Clear text offeres > > 1) password remindes > > 2) Less security = more performance > > > > The more you hash and secure things, the slower they will be. however > this > is not sucha worry for just logins. > > And instead of password reminder you can offer a "Generate new > password" > feature. > > > > The problem with just implementing this into 1.5.. its no so > straightforward, you need to fix data for existing passwords as well. > > > > - Jonathan ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel |
From: Jonathan M. <jon...@jo...> - 2005-04-01 08:18:49
|
1.6 is still .net 1.1 The permission system is like that of NTFS, ( we will still need to come = up with comfortable ui's and admins for this ) Modules are a good place to move to .net 2 Skins we prefer zen2...if we can can get it ;-) Also 1.1 although built with services in mind... and is still meant for browser. So NO thining the target market please :-) I don=92t think web = sites will become pass=E9 because of 2.0... personally I don=92t like = installing a bunch of things.... End users will not want to install programs just so = they can visit one site.. even if it is a rainbow site ;-) It is = unrealistic... at least in the near future. So you have to keep the solutions to things that function on browser. I don=92t know what you mean by c# running on the browser....client = side? Unless you meant in a windows app. I have used javascript for encrypt/decrypt before, but as you said = it=92s a little bit limited.=20 If we are looking to encrypt content Items you mentioned TripleDES or Rijndael ... can you elaborate a little on the whole process of storing = the encrypted items in db We need super fast runtime encryption/decryption of the data. The data = still hits the client ( if approved content, since content ahs permissions, assuming all contnetn has default anonymous allowed, but portal admin = chose to encrypt data in db )...then this data can be served to anyone using = the proper channel... a module or whatever, just not hacking the DB... The other factor is that permissions are hierarchy, so we get big performance considerations there. You need to check things on=20 a) Portal -> page -> module -> ContentItem ( Then if module has = attachments) You have to continue checking all the attachments to make sure they have rights to see them. This could potentially become a long running strech = if we are not careful. -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jeffrey MRA Sent: Friday, April 01, 2005 9:49 AM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security Read my last reply before this one please. ASP 2.0 has some very good features; are we talking about using any of = them or making new ones? I'd opted to roll my own if security is really and = issue and if you are going to spend a lot of CPU time then it better be. Now I have to look at two cases here so for argument sakes I'm going to assume that we talking about 1.6 and ASP 2.0 and make one rule; that = this is going to be a secure communication as we can for the effort; CPU time is = a premium it can make or break your site; load factors and farming all = factor in; I have an ideal solution I have used for years and it will work even better with ASP 2.0; Windows Applications... What this is a web site you say; ASP 2.0 makes Window apps live update feature so easy web sites my become posse; you simple write a Windows app to use your SQL server and = then all your CPU time is on the client end and the encryption isn't done via = a browser at all but in the Windows Application; this runs in Mono LAN so Linux users can breath again; even MAC will be able to run these new C# Window apps; in fact you can do the whole web site in a Windows app. Now the second case:=20 Encryption of large amounts of data is time consuming; keep in mind = there are many ways to do this; I still like the three key system; but with a twist from the last one I described; public is given to all authorized users; private is the users log on password and fixed is again for the portal. Client side decryption can be done using C# or JAVA script = (Limited) or signed JAVA classes (Expensive and Limited); I would use C# even = though you might limit your target base; always a trade off. Hash is out of the question for data content; TripleDES or Rijndael are both good; the = first is faster from my test but the second more secure. You hash the three keys together to make a password for the following. public static void Encrypt(string fileIn, string fileOut, string = password)=20 {=20 if (password =3D=3D null) return; if (password.Trim().Length =3D=3D 0) return; // First we are going to open the file streams=20 FileStream FileStreamIn =3D new FileStream(fileIn, FileMode.Open, FileAccess.Read);=20 FileStream FileStreamOut =3D new FileStream(fileOut, = FileMode.OpenOrCreate, FileAccess.Write);=20 // Then we are going to derive a Key and=20 // an IV from the Password and create an algorithm=20 PasswordDeriveBytes ThisPasswordDeriveByte =3D new PasswordDeriveBytes(password, new byte[] {0x49, 0x76, 0x61, 0x6e, 0x20, 0x4d, 0x65, 0x64, 0x76, 0x65, 0x64, 0x65, 0x76});=20 #if (UseTripleDES) TripleDES CryptoAlgorithm =3D TripleDES.Create();=20 CryptoAlgorithm.Key =3D ThisPasswordDeriveByte.GetBytes(16);=20 CryptoAlgorithm.IV =3D ThisPasswordDeriveByte.GetBytes(8);=20 #endif #if (UseRijndael) Rijndael CryptoAlgorithm =3D Rijndael.Create();=20 CryptoAlgorithm.Key =3D ThisPasswordDeriveByte.GetBytes(32);=20 CryptoAlgorithm.IV =3D ThisPasswordDeriveByte.GetBytes(16);=20 #endif // Now create a crypto stream through which we are going to be pumping = data. // Our fileOut is going to be receiving the encrypted bytes.=20 CryptoStream ThisCryptoStream =3D new CryptoStream(FileStreamOut, CryptoAlgorithm.CreateEncryptor(), CryptoStreamMode.Write);=20 // Now will will initialize a Buffer=20 // and will be processing the input file in chunks.=20 // This is done to avoid reading the whole file=20 // (which can be huge) into memory.=20 int BufferLen =3D 4096;=20 byte[] Buffer =3D new byte[BufferLen];=20 int BytesRead;=20 do=20 {=20 // read a chunk of data from the input file=20 BytesRead =3D FileStreamIn.Read(Buffer, 0, BufferLen);=20 // encrypt it=20 ThisCryptoStream.Write(Buffer, 0, BytesRead);=20 } while(BytesRead !=3D 0);=20 // close everything=20 // this will also close the unrelying FileStreamOut stream ThisCryptoStream.Close();=20 FileStreamIn.Close(); =20 } =20 =20 public static void Decrypt(string fileIn, string fileOut, string = password)=20 {=20 if (password =3D=3D null) return; if (password.Trim().Length =3D=3D 0) return; // First we are going to open the file streams=20 FileStream FileStreamIn =3D new FileStream(fileIn, FileMode.Open, FileAccess.Read);=20 FileStream FileStreamOut =3D new FileStream(fileOut, = FileMode.OpenOrCreate, FileAccess.Write);=20 // Then we are going to derive a Key and=20 // an IV from the Password and create an algorithm=20 PasswordDeriveBytes ThisPasswordDeriveByte =3D new PasswordDeriveBytes(password, new byte[] {0x49, 0x76, 0x61, 0x6e, 0x20, 0x4d, 0x65, 0x64, 0x76, 0x65, 0x64, 0x65, 0x76});=20 #if (UseTripleDES) TripleDES CryptoAlgorithm =3D TripleDES.Create();=20 CryptoAlgorithm.Key =3D ThisPasswordDeriveByte.GetBytes(16);=20 CryptoAlgorithm.IV =3D ThisPasswordDeriveByte.GetBytes(8);=20 #endif #if (UseRijndael) Rijndael CryptoAlgorithm =3D Rijndael.Create();=20 CryptoAlgorithm.Key =3D ThisPasswordDeriveByte.GetBytes(32);=20 CryptoAlgorithm.IV =3D ThisPasswordDeriveByte.GetBytes(16);=20 #endif // Now create a crypto stream through which we are going to be pumping = data. // Our fileOut is going to be receiving the Decrypted bytes.=20 CryptoStream ThisCryptoStream =3D new CryptoStream(FileStreamOut, CryptoAlgorithm.CreateDecryptor(), CryptoStreamMode.Write);=20 // Now will will initialize a Buffer=20 // and will be processing the input file in chunks.=20 // This is done to avoid reading the=20 // whole file (which can be huge) into memory.=20 int BufferLen =3D 4096;=20 byte[] Buffer =3D new byte[BufferLen];=20 int BytesRead;=20 do=20 {=20 // read a chunk of data from the input file=20 BytesRead =3D FileStreamIn.Read(Buffer, 0, BufferLen);=20 // Decrypt it=20 ThisCryptoStream.Write(Buffer, 0, BytesRead);=20 } while(BytesRead !=3D 0);=20 // close everything=20 ThisCryptoStream.Close(); // this will also close the unrelying FileStreamOut stream=20 FileStreamIn.Close(); =20 } I never tried this in a client code; but if C# code truly can run client side this should work; by the way these are very good functions I hope = you enjoy them as much as I did. As far as links go a search engine would drive me crazy answering a = question I already know; I could find worse sources of info and some might think better; but I say if it works good use it; it's simple and proven the = key is in the keys; three keys: public, private and fixed; how much more secure = to do need it? Jeff Flesher -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jonathan Minond Sent: Thursday, March 31, 2005 11:31 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security Also... One of the plans in 1.6 is that almost everything is encryptable,=20 Meaning you can encrypt all your data from content not just passwords = :-) But this is all server side so far....=20 Can you provide some links on acceptable 2 way hash solutions? -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jeffrey MRA Sent: Friday, April 01, 2005 4:21 AM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security I don't agree with it being a performance issue; we are talking about = one field here; not many users have passwords with more than 10 characters; = what are we talking about is microseconds of computer CPU time. There is no software to install with the function I included; nor is there a reason = to use or offer to use more than one option for encryption; overkill.=20 As far as changing the database; it is not need; check to see if the password is in clear text; if so use it; if not then use the encryption method; keep it simple (KISS). This is not rocket science it's the = ability to encrypt passwords to make a secure or more secure system.=20 I will also disagree as that sending password reminder is a good thing; = it's not; in fact it is a serious security birch; at least with a password = reset you can add a traceable element to the transaction; keep in mind if = someone stills your email and than ask for a password and as is you just hand it out; this happens all the time; I know that not to long ago someone here = had their email stolen; now what if they used it to hack his web site?=20 I believe fully in security and all I'm suggesting is the bare minimum; = but your right; we need to explore all options and let everyone let there = option known; I value your option but I ask you to error on the side of good judgment; in other words come up with a good argument. Ask yourself what = you think a customer wants; as programmers we some things get myopic and = can't see the obvious; if this is an e-commerce site (and I think it is or can = be) then where is the security? I can come up with far too many arguments = for security and none for not having any; that's just my option and all most = 30 years as a computer programmer.=20 Jeff Flesher -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jonathan Minond Sent: Thursday, March 31, 2005 2:24 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security Would that not require end users to install extra things beyond a = browser? Like an email client with that supports is, or some way to manage the = key? Seems like it gets complicated. Maybe something to consider as one of = the options for 1.6. We can technically offer sever options, that are Site = or Portal admin defined.=20 As a default for the application I wouldn't suggest it. I suggest = default is simple hash with a new password generator. Then a user can log in and = edit their profile and password again. Why don't we get a list of the options? And then maybe we can start = looking at how to handle this. We also don't want to go to crazy... letting = people have so many options. I think standard are=20 Clear text MD5 SHA128 SHA256 SHA512 Etc... Anything over 256 is already costing a lot performance wise, but I = suppose if you want to potentially have rainbow support enterprise, and economic type systems you need to offer high end...=20 I don't think any of this is a rush decisions, but we should get a list = of options that people agree rb should support. My opinion is that we = should not force end users to rely much on extra things beyond the browser as = far as core features are concerned. - Jonathan -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of = Pekka Ylenius Sent: Thursday, March 31, 2005 10:34 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security How about 2way encryption... It is possible to return password but it is not clear text. -----Original Message----- From: "Jonathan Minond" <jon...@jo...> To: <rai...@li...> Date: Thu, 31 Mar 2005 21:16:29 +0200 Subject: RE: [Rainbowportal-devel] Security > Clear text offeres >=20 > 1) password remindes >=20 > 2) Less security =3D more performance >=20 > =20 >=20 > The more you hash and secure things, the slower they will be. however > this > is not sucha worry for just logins. >=20 > And instead of password reminder you can offer a "Generate new > password" > feature. >=20 > =20 >=20 > The problem with just implementing this into 1.5.. its no so > straightforward, you need to fix data for existing passwords as well. >=20 > =20 >=20 > - Jonathan ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel |
From: Lars G. <lgr...@ya...> - 2005-04-01 11:37:28
|
We could use MD5 to the password problem. But then we have to generate a new password to the user requesting this. http://userpages.umbc.edu/~mabzug1/cs/md5/md5.html Lars Grøtteland Prodit AS Norway __________________________________ Do you Yahoo!? Yahoo! Mail - 250MB free storage. Do more. Manage less. http://info.mail.yahoo.com/mail_250 |
From: William F. <WF...@im...> - 2005-04-01 16:51:21
|
Go look at the security related enterprise library blocks. They have = everything we need even if you think they are slow. -----Original Message----- From: rai...@li... = [mailto:rai...@li...] On Behalf Of = Jonathan Minond Sent: Friday, April 01, 2005 12:16 AM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security 1.6 is still .net 1.1 The permission system is like that of NTFS, ( we will still need to come = up with comfortable ui's and admins for this ) Modules are a good place to move to .net 2 Skins we prefer zen2...if we can can get it ;-) Also 1.1 although built with services in mind... and is still meant for browser. So NO thining the target market please :-) I don't think web = sites will become pass=E9 because of 2.0... personally I don't like installing = a bunch of things.... End users will not want to install programs just so = they can visit one site.. even if it is a rainbow site ;-) It is = unrealistic... at least in the near future. So you have to keep the solutions to things that function on browser. I don't know what you mean by c# running on the browser....client side? Unless you meant in a windows app. I have used javascript for encrypt/decrypt before, but as you said it's = a little bit limited.=20 If we are looking to encrypt content Items you mentioned TripleDES or Rijndael ... can you elaborate a little on the whole process of storing = the encrypted items in db We need super fast runtime encryption/decryption of the data. The data = still hits the client ( if approved content, since content ahs permissions, assuming all contnetn has default anonymous allowed, but portal admin = chose to encrypt data in db )...then this data can be served to anyone using = the proper channel... a module or whatever, just not hacking the DB... The other factor is that permissions are hierarchy, so we get big performance considerations there. You need to check things on=20 a) Portal -> page -> module -> ContentItem ( Then if module has = attachments) You have to continue checking all the attachments to make sure they have rights to see them. This could potentially become a long running strech = if we are not careful. -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jeffrey MRA Sent: Friday, April 01, 2005 9:49 AM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security Read my last reply before this one please. ASP 2.0 has some very good features; are we talking about using any of = them or making new ones? I'd opted to roll my own if security is really and = issue and if you are going to spend a lot of CPU time then it better be. Now I have to look at two cases here so for argument sakes I'm going to assume that we talking about 1.6 and ASP 2.0 and make one rule; that = this is going to be a secure communication as we can for the effort; CPU time is = a premium it can make or break your site; load factors and farming all = factor in; I have an ideal solution I have used for years and it will work even better with ASP 2.0; Windows Applications... What this is a web site you say; ASP 2.0 makes Window apps live update feature so easy web sites my become posse; you simple write a Windows app to use your SQL server and = then all your CPU time is on the client end and the encryption isn't done via = a browser at all but in the Windows Application; this runs in Mono LAN so Linux users can breath again; even MAC will be able to run these new C# Window apps; in fact you can do the whole web site in a Windows app. Now the second case:=20 Encryption of large amounts of data is time consuming; keep in mind = there are many ways to do this; I still like the three key system; but with a twist from the last one I described; public is given to all authorized users; private is the users log on password and fixed is again for the portal. Client side decryption can be done using C# or JAVA script = (Limited) or signed JAVA classes (Expensive and Limited); I would use C# even = though you might limit your target base; always a trade off. Hash is out of the question for data content; TripleDES or Rijndael are both good; the = first is faster from my test but the second more secure. You hash the three keys together to make a password for the following. public static void Encrypt(string fileIn, string fileOut, string = password)=20 {=20 if (password =3D=3D null) return; if (password.Trim().Length =3D=3D 0) return; // First we are going to open the file streams=20 FileStream FileStreamIn =3D new FileStream(fileIn, FileMode.Open, FileAccess.Read);=20 FileStream FileStreamOut =3D new FileStream(fileOut, = FileMode.OpenOrCreate, FileAccess.Write);=20 // Then we are going to derive a Key and=20 // an IV from the Password and create an algorithm=20 PasswordDeriveBytes ThisPasswordDeriveByte =3D new PasswordDeriveBytes(password, new byte[] {0x49, 0x76, 0x61, 0x6e, 0x20, 0x4d, 0x65, 0x64, 0x76, 0x65, 0x64, 0x65, 0x76});=20 #if (UseTripleDES) TripleDES CryptoAlgorithm =3D TripleDES.Create();=20 CryptoAlgorithm.Key =3D ThisPasswordDeriveByte.GetBytes(16);=20 CryptoAlgorithm.IV =3D ThisPasswordDeriveByte.GetBytes(8);=20 #endif #if (UseRijndael) Rijndael CryptoAlgorithm =3D Rijndael.Create();=20 CryptoAlgorithm.Key =3D ThisPasswordDeriveByte.GetBytes(32);=20 CryptoAlgorithm.IV =3D ThisPasswordDeriveByte.GetBytes(16);=20 #endif // Now create a crypto stream through which we are going to be pumping = data. // Our fileOut is going to be receiving the encrypted bytes.=20 CryptoStream ThisCryptoStream =3D new CryptoStream(FileStreamOut, CryptoAlgorithm.CreateEncryptor(), CryptoStreamMode.Write);=20 // Now will will initialize a Buffer=20 // and will be processing the input file in chunks.=20 // This is done to avoid reading the whole file=20 // (which can be huge) into memory.=20 int BufferLen =3D 4096;=20 byte[] Buffer =3D new byte[BufferLen];=20 int BytesRead;=20 do=20 {=20 // read a chunk of data from the input file=20 BytesRead =3D FileStreamIn.Read(Buffer, 0, BufferLen);=20 // encrypt it=20 ThisCryptoStream.Write(Buffer, 0, BytesRead);=20 } while(BytesRead !=3D 0);=20 // close everything=20 // this will also close the unrelying FileStreamOut stream ThisCryptoStream.Close();=20 FileStreamIn.Close(); =20 } =20 =20 public static void Decrypt(string fileIn, string fileOut, string = password)=20 {=20 if (password =3D=3D null) return; if (password.Trim().Length =3D=3D 0) return; // First we are going to open the file streams=20 FileStream FileStreamIn =3D new FileStream(fileIn, FileMode.Open, FileAccess.Read);=20 FileStream FileStreamOut =3D new FileStream(fileOut, = FileMode.OpenOrCreate, FileAccess.Write);=20 // Then we are going to derive a Key and=20 // an IV from the Password and create an algorithm=20 PasswordDeriveBytes ThisPasswordDeriveByte =3D new PasswordDeriveBytes(password, new byte[] {0x49, 0x76, 0x61, 0x6e, 0x20, 0x4d, 0x65, 0x64, 0x76, 0x65, 0x64, 0x65, 0x76});=20 #if (UseTripleDES) TripleDES CryptoAlgorithm =3D TripleDES.Create();=20 CryptoAlgorithm.Key =3D ThisPasswordDeriveByte.GetBytes(16);=20 CryptoAlgorithm.IV =3D ThisPasswordDeriveByte.GetBytes(8);=20 #endif #if (UseRijndael) Rijndael CryptoAlgorithm =3D Rijndael.Create();=20 CryptoAlgorithm.Key =3D ThisPasswordDeriveByte.GetBytes(32);=20 CryptoAlgorithm.IV =3D ThisPasswordDeriveByte.GetBytes(16);=20 #endif // Now create a crypto stream through which we are going to be pumping = data. // Our fileOut is going to be receiving the Decrypted bytes.=20 CryptoStream ThisCryptoStream =3D new CryptoStream(FileStreamOut, CryptoAlgorithm.CreateDecryptor(), CryptoStreamMode.Write);=20 // Now will will initialize a Buffer=20 // and will be processing the input file in chunks.=20 // This is done to avoid reading the=20 // whole file (which can be huge) into memory.=20 int BufferLen =3D 4096;=20 byte[] Buffer =3D new byte[BufferLen];=20 int BytesRead;=20 do=20 {=20 // read a chunk of data from the input file=20 BytesRead =3D FileStreamIn.Read(Buffer, 0, BufferLen);=20 // Decrypt it=20 ThisCryptoStream.Write(Buffer, 0, BytesRead);=20 } while(BytesRead !=3D 0);=20 // close everything=20 ThisCryptoStream.Close(); // this will also close the unrelying FileStreamOut stream=20 FileStreamIn.Close(); =20 } I never tried this in a client code; but if C# code truly can run client side this should work; by the way these are very good functions I hope = you enjoy them as much as I did. As far as links go a search engine would drive me crazy answering a = question I already know; I could find worse sources of info and some might think better; but I say if it works good use it; it's simple and proven the = key is in the keys; three keys: public, private and fixed; how much more secure = to do need it? Jeff Flesher -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jonathan Minond Sent: Thursday, March 31, 2005 11:31 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security Also... One of the plans in 1.6 is that almost everything is encryptable,=20 Meaning you can encrypt all your data from content not just passwords = :-) But this is all server side so far....=20 Can you provide some links on acceptable 2 way hash solutions? -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jeffrey MRA Sent: Friday, April 01, 2005 4:21 AM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security I don't agree with it being a performance issue; we are talking about = one field here; not many users have passwords with more than 10 characters; = what are we talking about is microseconds of computer CPU time. There is no software to install with the function I included; nor is there a reason = to use or offer to use more than one option for encryption; overkill.=20 As far as changing the database; it is not need; check to see if the password is in clear text; if so use it; if not then use the encryption method; keep it simple (KISS). This is not rocket science it's the = ability to encrypt passwords to make a secure or more secure system.=20 I will also disagree as that sending password reminder is a good thing; = it's not; in fact it is a serious security birch; at least with a password = reset you can add a traceable element to the transaction; keep in mind if = someone stills your email and than ask for a password and as is you just hand it out; this happens all the time; I know that not to long ago someone here = had their email stolen; now what if they used it to hack his web site?=20 I believe fully in security and all I'm suggesting is the bare minimum; = but your right; we need to explore all options and let everyone let there = option known; I value your option but I ask you to error on the side of good judgment; in other words come up with a good argument. Ask yourself what = you think a customer wants; as programmers we some things get myopic and = can't see the obvious; if this is an e-commerce site (and I think it is or can = be) then where is the security? I can come up with far too many arguments = for security and none for not having any; that's just my option and all most = 30 years as a computer programmer.=20 Jeff Flesher -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jonathan Minond Sent: Thursday, March 31, 2005 2:24 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security Would that not require end users to install extra things beyond a = browser? Like an email client with that supports is, or some way to manage the = key? Seems like it gets complicated. Maybe something to consider as one of = the options for 1.6. We can technically offer sever options, that are Site = or Portal admin defined.=20 As a default for the application I wouldn't suggest it. I suggest = default is simple hash with a new password generator. Then a user can log in and = edit their profile and password again. Why don't we get a list of the options? And then maybe we can start = looking at how to handle this. We also don't want to go to crazy... letting = people have so many options. I think standard are=20 Clear text MD5 SHA128 SHA256 SHA512 Etc... Anything over 256 is already costing a lot performance wise, but I = suppose if you want to potentially have rainbow support enterprise, and economic type systems you need to offer high end...=20 I don't think any of this is a rush decisions, but we should get a list = of options that people agree rb should support. My opinion is that we = should not force end users to rely much on extra things beyond the browser as = far as core features are concerned. - Jonathan -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of = Pekka Ylenius Sent: Thursday, March 31, 2005 10:34 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security How about 2way encryption... It is possible to return password but it is not clear text. -----Original Message----- From: "Jonathan Minond" <jon...@jo...> To: <rai...@li...> Date: Thu, 31 Mar 2005 21:16:29 +0200 Subject: RE: [Rainbowportal-devel] Security > Clear text offeres >=20 > 1) password remindes >=20 > 2) Less security =3D more performance >=20 > =20 >=20 > The more you hash and secure things, the slower they will be. however > this > is not sucha worry for just logins. >=20 > And instead of password reminder you can offer a "Generate new > password" > feature. >=20 > =20 >=20 > The problem with just implementing this into 1.5.. its no so > straightforward, you need to fix data for existing passwords as well. >=20 > =20 >=20 > - Jonathan ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel |
From: Jeffrey M. <je...@my...> - 2005-04-01 18:42:24
|
I think it was late last night when I wrote this; what I meant was that = ASP 2.0 Window Apps will make this kind of secure communications that is = being done in browsers now posse; not that web sites in general; effected web sites will be Chat and other two way encrypted communications; this is because of the ease of deploying Windows apps and doing live updates and = the speed gained by using them over a browser that doesn't leaned itself = well to this. I was referring to running C# in scripts just like java scripts; but = using .Nets built in encryption. There are many choices in encryption; some = are better suited for some needs than others; some are over kill; others are slower; but all of them depend on the type of data being encrypted. One thing to think about is custom compression functions with encryption; = this would improve the transmission speed. I chose this function because of = ease of use and speed; by using a define statement you can bench mark each = method or make it and if statement and allow the admin to chose method; keep in mind that you can't switch on the fly once you save a format to the = database without using the original method to decrypt it. Storing encrypted data is no deferent than any other data with one exception; control characters; I found one method of encryption that had = a nasty habit of using the "'" tick character that causes run time errors = if not handled correctly; I have found it better to use the StringValue.Replace("'","=92"); as part of saving any data to SQL; it = doesn't (doesn=92t) change the use of the character and most people don't ever = notice it; but you can't do this with encrypted data; in fact you have to make = sure that you are not changing the data at all during the save and retrieve operation; this may sound like a given but I find that HTML optimization = is used a lot in saving data to the database and this would corrupt = encrypted data; this is one reason why I say the hash function I submitted is the = only option for passwords; it makes it easy to determine if it is encrypted = using a Regular Expression since the format will never change; whereas other methods would make it impossible to tell encrypted data from clear text; also keep in mind that this type of hash data is not an encryption = method at all; in fact you can't get the original password out of the hash data; = all you can do is compare the value of one hashed password to the stored = value; which is the whole point to password security; don't store the password = at all; thus stating there are other encryption methods like MD5, SHA128... = is missing this point entirely. Jeff Flesher -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jonathan Minond Sent: Friday, April 01, 2005 1:19 AM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security 1.6 is still .net 1.1 The permission system is like that of NTFS, ( we will still need to come = up with comfortable ui's and admins for this ) Modules are a good place to move to .net 2 Skins we prefer zen2...if we can can get it ;-) Also 1.1 although built with services in mind... and is still meant for browser. So NO thining the target market please :-) I don=92t think web = sites will become pass=E9 because of 2.0... personally I don=92t like = installing a bunch of things.... End users will not want to install programs just so = they can visit one site.. even if it is a rainbow site ;-) It is = unrealistic... at least in the near future. So you have to keep the solutions to things that function on browser. I don=92t know what you mean by c# running on the browser....client = side? Unless you meant in a windows app. I have used javascript for encrypt/decrypt before, but as you said = it=92s a little bit limited.=20 If we are looking to encrypt content Items you mentioned TripleDES or Rijndael ... can you elaborate a little on the whole process of storing = the encrypted items in db We need super fast runtime encryption/decryption of the data. The data = still hits the client ( if approved content, since content ahs permissions, assuming all contnetn has default anonymous allowed, but portal admin = chose to encrypt data in db )...then this data can be served to anyone using = the proper channel... a module or whatever, just not hacking the DB... The other factor is that permissions are hierarchy, so we get big performance considerations there. You need to check things on=20 a) Portal -> page -> module -> ContentItem ( Then if module has = attachments) You have to continue checking all the attachments to make sure they have rights to see them. This could potentially become a long running strech = if we are not careful. -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jeffrey MRA Sent: Friday, April 01, 2005 9:49 AM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security Read my last reply before this one please. ASP 2.0 has some very good features; are we talking about using any of = them or making new ones? I'd opted to roll my own if security is really and = issue and if you are going to spend a lot of CPU time then it better be. Now I have to look at two cases here so for argument sakes I'm going to assume that we talking about 1.6 and ASP 2.0 and make one rule; that = this is going to be a secure communication as we can for the effort; CPU time is = a premium it can make or break your site; load factors and farming all = factor in; I have an ideal solution I have used for years and it will work even better with ASP 2.0; Windows Applications... What this is a web site you say; ASP 2.0 makes Window apps live update feature so easy web sites my become posse; you simple write a Windows app to use your SQL server and = then all your CPU time is on the client end and the encryption isn't done via = a browser at all but in the Windows Application; this runs in Mono LAN so Linux users can breath again; even MAC will be able to run these new C# Window apps; in fact you can do the whole web site in a Windows app. Now the second case:=20 Encryption of large amounts of data is time consuming; keep in mind = there are many ways to do this; I still like the three key system; but with a twist from the last one I described; public is given to all authorized users; private is the users log on password and fixed is again for the portal. Client side decryption can be done using C# or JAVA script = (Limited) or signed JAVA classes (Expensive and Limited); I would use C# even = though you might limit your target base; always a trade off. Hash is out of the question for data content; TripleDES or Rijndael are both good; the = first is faster from my test but the second more secure. You hash the three keys together to make a password for the following. public static void Encrypt(string fileIn, string fileOut, string = password)=20 {=20 if (password =3D=3D null) return; if (password.Trim().Length =3D=3D 0) return; // First we are going to open the file streams=20 FileStream FileStreamIn =3D new FileStream(fileIn, FileMode.Open, FileAccess.Read);=20 FileStream FileStreamOut =3D new FileStream(fileOut, = FileMode.OpenOrCreate, FileAccess.Write);=20 // Then we are going to derive a Key and=20 // an IV from the Password and create an algorithm=20 PasswordDeriveBytes ThisPasswordDeriveByte =3D new PasswordDeriveBytes(password, new byte[] {0x49, 0x76, 0x61, 0x6e, 0x20, 0x4d, 0x65, 0x64, 0x76, 0x65, 0x64, 0x65, 0x76});=20 #if (UseTripleDES) TripleDES CryptoAlgorithm =3D TripleDES.Create();=20 CryptoAlgorithm.Key =3D ThisPasswordDeriveByte.GetBytes(16);=20 CryptoAlgorithm.IV =3D ThisPasswordDeriveByte.GetBytes(8);=20 #endif #if (UseRijndael) Rijndael CryptoAlgorithm =3D Rijndael.Create();=20 CryptoAlgorithm.Key =3D ThisPasswordDeriveByte.GetBytes(32);=20 CryptoAlgorithm.IV =3D ThisPasswordDeriveByte.GetBytes(16);=20 #endif // Now create a crypto stream through which we are going to be pumping = data. // Our fileOut is going to be receiving the encrypted bytes.=20 CryptoStream ThisCryptoStream =3D new CryptoStream(FileStreamOut, CryptoAlgorithm.CreateEncryptor(), CryptoStreamMode.Write);=20 // Now will will initialize a Buffer=20 // and will be processing the input file in chunks.=20 // This is done to avoid reading the whole file=20 // (which can be huge) into memory.=20 int BufferLen =3D 4096;=20 byte[] Buffer =3D new byte[BufferLen];=20 int BytesRead;=20 do=20 {=20 // read a chunk of data from the input file=20 BytesRead =3D FileStreamIn.Read(Buffer, 0, BufferLen);=20 // encrypt it=20 ThisCryptoStream.Write(Buffer, 0, BytesRead);=20 } while(BytesRead !=3D 0);=20 // close everything=20 // this will also close the unrelying FileStreamOut stream ThisCryptoStream.Close();=20 FileStreamIn.Close(); =20 } =20 =20 public static void Decrypt(string fileIn, string fileOut, string = password)=20 {=20 if (password =3D=3D null) return; if (password.Trim().Length =3D=3D 0) return; // First we are going to open the file streams=20 FileStream FileStreamIn =3D new FileStream(fileIn, FileMode.Open, FileAccess.Read);=20 FileStream FileStreamOut =3D new FileStream(fileOut, = FileMode.OpenOrCreate, FileAccess.Write);=20 // Then we are going to derive a Key and=20 // an IV from the Password and create an algorithm=20 PasswordDeriveBytes ThisPasswordDeriveByte =3D new PasswordDeriveBytes(password, new byte[] {0x49, 0x76, 0x61, 0x6e, 0x20, 0x4d, 0x65, 0x64, 0x76, 0x65, 0x64, 0x65, 0x76});=20 #if (UseTripleDES) TripleDES CryptoAlgorithm =3D TripleDES.Create();=20 CryptoAlgorithm.Key =3D ThisPasswordDeriveByte.GetBytes(16);=20 CryptoAlgorithm.IV =3D ThisPasswordDeriveByte.GetBytes(8);=20 #endif #if (UseRijndael) Rijndael CryptoAlgorithm =3D Rijndael.Create();=20 CryptoAlgorithm.Key =3D ThisPasswordDeriveByte.GetBytes(32);=20 CryptoAlgorithm.IV =3D ThisPasswordDeriveByte.GetBytes(16);=20 #endif // Now create a crypto stream through which we are going to be pumping = data. // Our fileOut is going to be receiving the Decrypted bytes.=20 CryptoStream ThisCryptoStream =3D new CryptoStream(FileStreamOut, CryptoAlgorithm.CreateDecryptor(), CryptoStreamMode.Write);=20 // Now will will initialize a Buffer=20 // and will be processing the input file in chunks.=20 // This is done to avoid reading the=20 // whole file (which can be huge) into memory.=20 int BufferLen =3D 4096;=20 byte[] Buffer =3D new byte[BufferLen];=20 int BytesRead;=20 do=20 {=20 // read a chunk of data from the input file=20 BytesRead =3D FileStreamIn.Read(Buffer, 0, BufferLen);=20 // Decrypt it=20 ThisCryptoStream.Write(Buffer, 0, BytesRead);=20 } while(BytesRead !=3D 0);=20 // close everything=20 ThisCryptoStream.Close(); // this will also close the unrelying FileStreamOut stream=20 FileStreamIn.Close(); =20 } I never tried this in a client code; but if C# code truly can run client side this should work; by the way these are very good functions I hope = you enjoy them as much as I did. As far as links go a search engine would drive me crazy answering a = question I already know; I could find worse sources of info and some might think better; but I say if it works good use it; it's simple and proven the = key is in the keys; three keys: public, private and fixed; how much more secure = to do need it? Jeff Flesher -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jonathan Minond Sent: Thursday, March 31, 2005 11:31 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security Also... One of the plans in 1.6 is that almost everything is encryptable,=20 Meaning you can encrypt all your data from content not just passwords = :-) But this is all server side so far....=20 Can you provide some links on acceptable 2 way hash solutions? -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jeffrey MRA Sent: Friday, April 01, 2005 4:21 AM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security I don't agree with it being a performance issue; we are talking about = one field here; not many users have passwords with more than 10 characters; = what are we talking about is microseconds of computer CPU time. There is no software to install with the function I included; nor is there a reason = to use or offer to use more than one option for encryption; overkill.=20 As far as changing the database; it is not need; check to see if the password is in clear text; if so use it; if not then use the encryption method; keep it simple (KISS). This is not rocket science it's the = ability to encrypt passwords to make a secure or more secure system.=20 I will also disagree as that sending password reminder is a good thing; = it's not; in fact it is a serious security birch; at least with a password = reset you can add a traceable element to the transaction; keep in mind if = someone stills your email and than ask for a password and as is you just hand it out; this happens all the time; I know that not to long ago someone here = had their email stolen; now what if they used it to hack his web site?=20 I believe fully in security and all I'm suggesting is the bare minimum; = but your right; we need to explore all options and let everyone let there = option known; I value your option but I ask you to error on the side of good judgment; in other words come up with a good argument. Ask yourself what = you think a customer wants; as programmers we some things get myopic and = can't see the obvious; if this is an e-commerce site (and I think it is or can = be) then where is the security? I can come up with far too many arguments = for security and none for not having any; that's just my option and all most = 30 years as a computer programmer.=20 Jeff Flesher -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jonathan Minond Sent: Thursday, March 31, 2005 2:24 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security Would that not require end users to install extra things beyond a = browser? Like an email client with that supports is, or some way to manage the = key? Seems like it gets complicated. Maybe something to consider as one of = the options for 1.6. We can technically offer sever options, that are Site = or Portal admin defined.=20 As a default for the application I wouldn't suggest it. I suggest = default is simple hash with a new password generator. Then a user can log in and = edit their profile and password again. Why don't we get a list of the options? And then maybe we can start = looking at how to handle this. We also don't want to go to crazy... letting = people have so many options. I think standard are=20 Clear text MD5 SHA128 SHA256 SHA512 Etc... Anything over 256 is already costing a lot performance wise, but I = suppose if you want to potentially have rainbow support enterprise, and economic type systems you need to offer high end...=20 I don't think any of this is a rush decisions, but we should get a list = of options that people agree rb should support. My opinion is that we = should not force end users to rely much on extra things beyond the browser as = far as core features are concerned. - Jonathan -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of = Pekka Ylenius Sent: Thursday, March 31, 2005 10:34 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security How about 2way encryption... It is possible to return password but it is not clear text. -----Original Message----- From: "Jonathan Minond" <jon...@jo...> To: <rai...@li...> Date: Thu, 31 Mar 2005 21:16:29 +0200 Subject: RE: [Rainbowportal-devel] Security > Clear text offeres >=20 > 1) password remindes >=20 > 2) Less security =3D more performance >=20 > =20 >=20 > The more you hash and secure things, the slower they will be. however > this > is not sucha worry for just logins. >=20 > And instead of password reminder you can offer a "Generate new > password" > feature. >=20 > =20 >=20 > The problem with just implementing this into 1.5.. its no so > straightforward, you need to fix data for existing passwords as well. >=20 > =20 >=20 > - Jonathan ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel |
From: Jonathan M. <jon...@jo...> - 2005-04-02 14:46:41
|
I understand everything you are saying about the encryption and hashing. = I don=92t think we have a disagreement here.... passwords should be = hashed... two way though unless I am still not understanding means windows apps... = or things installed on client. You can hash it in Javascript or whatever = before sending, which is one thing, but like you said once it's hashed, it's hashed, no going back.=20 I still don=92t like the idea of planning anything around window apps or anything that requires users to install things. You can build a wealth = of services that can use window apps, to create applications for = controlling content, manipulating data in db, etc... but in the end, RB, 1.5 and 1.6 = are meant to server up content anywhere anytime to anyone, as well as the = main administration must also be online.=20 Added value apps that would make use of services provided to deal with = the data are one thing, for example you mentioned a chat... chat should be browser... not window app...this is my opinion. Windows apps will not replace the browser in any way, any time soon. As far as speed, it=92s a matter of connections and bandwidth, not browser limitations. People = will want to shop online, not install the stores window app to buy their products, people want to chat online, not install chat software that communicates with whatever chat server. Anyway, I feel like I am going in a circle on this one.... I liked your solution to passwords, with password secret and multiple keys to get at = the password and I feel that this should begin to get moved on immediately starting with 1.5 and including the solution in 1.6 using the user = profiles ( reminder we need to make to spec out the solution properly so bill can = add the required fields to the user tables ) are you taking the lead in implementing this for 1.5 and guiding the process to 1.6? I am not sure I fully understand what your solution for 2 way encryption = on the data is. I'll accept anything that leaves your solution to the browser... because that is the main goal I believe. User enters item = data online, it gets encrypted, stored in db, then if authorized he can view = it devrypted. Do this on the browser without installing any window apps, = java applets, activeX or anything and then we have a solution that is cross browser and I believe will be accepted by everyone. Don=92t forget you = must rely on the portal/site/module/item setting that even decides if said = data is even encrypted.=20 =20 =20 -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jeffrey MRA Sent: Friday, April 01, 2005 8:42 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security =20 I think it was late last night when I wrote this; what I meant was that = ASP 2.0 Window Apps will make this kind of secure communications that is = being done in browsers now posse; not that web sites in general; effected web sites will be Chat and other two way encrypted communications; this is because of the ease of deploying Windows apps and doing live updates and = the speed gained by using them over a browser that doesn't leaned itself = well to this. =20 I was referring to running C# in scripts just like java scripts; but = using .Nets built in encryption. There are many choices in encryption; some = are better suited for some needs than others; some are over kill; others are slower; but all of them depend on the type of data being encrypted. One thing to think about is custom compression functions with encryption; = this would improve the transmission speed. I chose this function because of = ease of use and speed; by using a define statement you can bench mark each = method or make it and if statement and allow the admin to chose method; keep in mind that you can't switch on the fly once you save a format to the = database without using the original method to decrypt it. Storing encrypted data is no deferent than any other data with one exception; control characters; I found one method of encryption that had = a nasty habit of using the "'" tick character that causes run time errors = if not handled correctly; I have found it better to use the StringValue.Replace("'","=92"); as part of saving any data to SQL; it = doesn't (doesn=92t) change the use of the character and most people don't ever = notice it; but you can't do this with encrypted data; in fact you have to make = sure that you are not changing the data at all during the save and retrieve operation; this may sound like a given but I find that HTML optimization = is used a lot in saving data to the database and this would corrupt = encrypted data; this is one reason why I say the hash function I submitted is the = only option for passwords; it makes it easy to determine if it is encrypted = using a Regular Expression since the format will never change; whereas other methods would make it impossible to tell encrypted data from clear text; also keep in mind that this type of hash data is not an encryption = method at all; in fact you can't get the original password out of the hash data; = all you can do is compare the value of one hashed password to the stored = value; which is the whole point to password security; don't store the password = at all; thus stating there are other encryption methods like MD5, SHA128... = is missing this point entirely. =20 Jeff Flesher =20 -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jonathan Minond Sent: Friday, April 01, 2005 1:19 AM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security =20 1.6 is still .net 1.1 The permission system is like that of NTFS, ( we will still need to come = up with comfortable ui's and admins for this ) Modules are a good place to move to .net 2 Skins we prefer zen2...if we can can get it ;-) =20 Also 1.1 although built with services in mind... and is still meant for browser. So NO thining the target market please :-) I don=92t think web = sites will become pass=E9 because of 2.0... personally I don=92t like = installing a bunch of things.... End users will not want to install programs just so = they can visit one site.. even if it is a rainbow site ;-) It is = unrealistic... at least in the near future. So you have to keep the solutions to things that function on browser. I don=92t know what you mean by c# running on the browser....client = side? Unless you meant in a windows app. I have used javascript for encrypt/decrypt before, but as you said = it=92s a little bit limited.=20 If we are looking to encrypt content Items you mentioned TripleDES or Rijndael ... can you elaborate a little on the whole process of storing = the encrypted items in db We need super fast runtime encryption/decryption of the data. The data = still hits the client ( if approved content, since content ahs permissions, assuming all contnetn has default anonymous allowed, but portal admin = chose to encrypt data in db )...then this data can be served to anyone using = the proper channel... a module or whatever, just not hacking the DB... The other factor is that permissions are hierarchy, so we get big performance considerations there. You need to check things on=20 =20 a) Portal -> page -> module -> ContentItem ( Then if module has = attachments) You have to continue checking all the attachments to make sure they have rights to see them. This could potentially become a long running strech = if we are not careful. =20 =20 =20 =20 =20 -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jeffrey MRA Sent: Friday, April 01, 2005 9:49 AM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security =20 Read my last reply before this one please. ASP 2.0 has some very good features; are we talking about using any of = them or making new ones? I'd opted to roll my own if security is really and = issue and if you are going to spend a lot of CPU time then it better be. Now I have to look at two cases here so for argument sakes I'm going to assume that we talking about 1.6 and ASP 2.0 and make one rule; that = this is going to be a secure communication as we can for the effort; CPU time is = a premium it can make or break your site; load factors and farming all = factor in; I have an ideal solution I have used for years and it will work even better with ASP 2.0; Windows Applications... What this is a web site you say; ASP 2.0 makes Window apps live update feature so easy web sites my become posse; you simple write a Windows app to use your SQL server and = then all your CPU time is on the client end and the encryption isn't done via = a browser at all but in the Windows Application; this runs in Mono LAN so Linux users can breath again; even MAC will be able to run these new C# Window apps; in fact you can do the whole web site in a Windows app. Now the second case:=20 Encryption of large amounts of data is time consuming; keep in mind = there are many ways to do this; I still like the three key system; but with a twist from the last one I described; public is given to all authorized users; private is the users log on password and fixed is again for the portal. Client side decryption can be done using C# or JAVA script = (Limited) or signed JAVA classes (Expensive and Limited); I would use C# even = though you might limit your target base; always a trade off. Hash is out of the question for data content; TripleDES or Rijndael are both good; the = first is faster from my test but the second more secure. You hash the three keys together to make a password for the following. public static void Encrypt(string fileIn, string fileOut, string = password)=20 {=20 if (password =3D=3D null) return; if (password.Trim().Length =3D=3D 0) return; // First we are going to open the file streams=20 FileStream FileStreamIn =3D new FileStream(fileIn, FileMode.Open, FileAccess.Read);=20 FileStream FileStreamOut =3D new FileStream(fileOut, = FileMode.OpenOrCreate, FileAccess.Write);=20 // Then we are going to derive a Key and=20 // an IV from the Password and create an algorithm=20 PasswordDeriveBytes ThisPasswordDeriveByte =3D new PasswordDeriveBytes(password, new byte[] {0x49, 0x76, 0x61, 0x6e, 0x20, 0x4d, 0x65, 0x64, 0x76, 0x65, 0x64, 0x65, 0x76});=20 #if (UseTripleDES) TripleDES CryptoAlgorithm =3D TripleDES.Create();=20 CryptoAlgorithm.Key =3D ThisPasswordDeriveByte.GetBytes(16);=20 CryptoAlgorithm.IV =3D ThisPasswordDeriveByte.GetBytes(8);=20 #endif #if (UseRijndael) Rijndael CryptoAlgorithm =3D Rijndael.Create();=20 CryptoAlgorithm.Key =3D ThisPasswordDeriveByte.GetBytes(32);=20 CryptoAlgorithm.IV =3D ThisPasswordDeriveByte.GetBytes(16);=20 #endif // Now create a crypto stream through which we are going to be pumping = data. =20 // Our fileOut is going to be receiving the encrypted bytes.=20 CryptoStream ThisCryptoStream =3D new CryptoStream(FileStreamOut, CryptoAlgorithm.CreateEncryptor(), CryptoStreamMode.Write);=20 // Now will will initialize a Buffer=20 // and will be processing the input file in chunks.=20 // This is done to avoid reading the whole file=20 // (which can be huge) into memory.=20 int BufferLen =3D 4096;=20 byte[] Buffer =3D new byte[BufferLen];=20 int BytesRead;=20 do=20 {=20 // read a chunk of data from the input file=20 BytesRead =3D FileStreamIn.Read(Buffer, 0, BufferLen);=20 // encrypt it=20 ThisCryptoStream.Write(Buffer, 0, BytesRead);=20 } while(BytesRead !=3D 0);=20 // close everything=20 // this will also close the unrelying FileStreamOut stream ThisCryptoStream.Close();=20 FileStreamIn.Close(); =20 } =20 =20 public static void Decrypt(string fileIn, string fileOut, string = password)=20 {=20 if (password =3D=3D null) return; if (password.Trim().Length =3D=3D 0) return; // First we are going to open the file streams=20 FileStream FileStreamIn =3D new FileStream(fileIn, FileMode.Open, FileAccess.Read);=20 FileStream FileStreamOut =3D new FileStream(fileOut, = FileMode.OpenOrCreate, FileAccess.Write);=20 // Then we are going to derive a Key and=20 // an IV from the Password and create an algorithm=20 PasswordDeriveBytes ThisPasswordDeriveByte =3D new PasswordDeriveBytes(password, new byte[] {0x49, 0x76, 0x61, 0x6e, 0x20, 0x4d, 0x65, 0x64, 0x76, 0x65, 0x64, 0x65, 0x76});=20 #if (UseTripleDES) TripleDES CryptoAlgorithm =3D TripleDES.Create();=20 CryptoAlgorithm.Key =3D ThisPasswordDeriveByte.GetBytes(16);=20 CryptoAlgorithm.IV =3D ThisPasswordDeriveByte.GetBytes(8);=20 #endif #if (UseRijndael) Rijndael CryptoAlgorithm =3D Rijndael.Create();=20 CryptoAlgorithm.Key =3D ThisPasswordDeriveByte.GetBytes(32);=20 CryptoAlgorithm.IV =3D ThisPasswordDeriveByte.GetBytes(16);=20 #endif // Now create a crypto stream through which we are going to be pumping = data. =20 // Our fileOut is going to be receiving the Decrypted bytes.=20 CryptoStream ThisCryptoStream =3D new CryptoStream(FileStreamOut, CryptoAlgorithm.CreateDecryptor(), CryptoStreamMode.Write);=20 // Now will will initialize a Buffer=20 // and will be processing the input file in chunks.=20 // This is done to avoid reading the=20 // whole file (which can be huge) into memory.=20 int BufferLen =3D 4096;=20 byte[] Buffer =3D new byte[BufferLen];=20 int BytesRead;=20 do=20 {=20 // read a chunk of data from the input file=20 BytesRead =3D FileStreamIn.Read(Buffer, 0, BufferLen);=20 // Decrypt it=20 ThisCryptoStream.Write(Buffer, 0, BytesRead);=20 } while(BytesRead !=3D 0);=20 // close everything=20 ThisCryptoStream.Close(); // this will also close the unrelying FileStreamOut stream=20 FileStreamIn.Close(); =20 } I never tried this in a client code; but if C# code truly can run client side this should work; by the way these are very good functions I hope = you enjoy them as much as I did. As far as links go a search engine would drive me crazy answering a = question I already know; I could find worse sources of info and some might think better; but I say if it works good use it; it's simple and proven the = key is in the keys; three keys: public, private and fixed; how much more secure = to do need it? =20 Jeff Flesher =20 -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jonathan Minond Sent: Thursday, March 31, 2005 11:31 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security =20 Also... One of the plans in 1.6 is that almost everything is encryptable,=20 Meaning you can encrypt all your data from content not just passwords = :-) But this is all server side so far....=20 Can you provide some links on acceptable 2 way hash solutions? =20 -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jeffrey MRA Sent: Friday, April 01, 2005 4:21 AM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security =20 I don't agree with it being a performance issue; we are talking about = one field here; not many users have passwords with more than 10 characters; = what are we talking about is microseconds of computer CPU time. There is no software to install with the function I included; nor is there a reason = to use or offer to use more than one option for encryption; overkill.=20 As far as changing the database; it is not need; check to see if the password is in clear text; if so use it; if not then use the encryption method; keep it simple (KISS). This is not rocket science it's the = ability to encrypt passwords to make a secure or more secure system.=20 I will also disagree as that sending password reminder is a good thing; = it's not; in fact it is a serious security birch; at least with a password = reset you can add a traceable element to the transaction; keep in mind if = someone stills your email and than ask for a password and as is you just hand it out; this happens all the time; I know that not to long ago someone here = had their email stolen; now what if they used it to hack his web site?=20 I believe fully in security and all I'm suggesting is the bare minimum; = but your right; we need to explore all options and let everyone let there = option known; I value your option but I ask you to error on the side of good judgment; in other words come up with a good argument. Ask yourself what = you think a customer wants; as programmers we some things get myopic and = can't see the obvious; if this is an e-commerce site (and I think it is or can = be) then where is the security? I can come up with far too many arguments = for security and none for not having any; that's just my option and all most = 30 years as a computer programmer.=20 =20 Jeff Flesher =20 -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jonathan Minond Sent: Thursday, March 31, 2005 2:24 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security =20 Would that not require end users to install extra things beyond a = browser? Like an email client with that supports is, or some way to manage the = key? Seems like it gets complicated. Maybe something to consider as one of = the options for 1.6. We can technically offer sever options, that are Site = or Portal admin defined.=20 As a default for the application I wouldn't suggest it. I suggest = default is simple hash with a new password generator. Then a user can log in and = edit their profile and password again. Why don't we get a list of the options? And then maybe we can start = looking at how to handle this. We also don't want to go to crazy... letting = people have so many options. I think standard are=20 Clear text MD5 SHA128 SHA256 SHA512 Etc... Anything over 256 is already costing a lot performance wise, but I = suppose if you want to potentially have rainbow support enterprise, and economic type systems you need to offer high end...=20 I don't think any of this is a rush decisions, but we should get a list = of options that people agree rb should support. My opinion is that we = should not force end users to rely much on extra things beyond the browser as = far as core features are concerned. =20 - Jonathan =20 -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of = Pekka Ylenius Sent: Thursday, March 31, 2005 10:34 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security =20 =20 How about 2way encryption... It is possible to return password but it is not clear text. =20 =20 -----Original Message----- From: "Jonathan Minond" <jon...@jo...> To: <rai...@li...> Date: Thu, 31 Mar 2005 21:16:29 +0200 Subject: RE: [Rainbowportal-devel] Security =20 > Clear text offeres >=20 > 1) password remindes >=20 > 2) Less security =3D more performance >=20 > =20 >=20 > The more you hash and secure things, the slower they will be. however > this > is not sucha worry for just logins. >=20 > And instead of password reminder you can offer a "Generate new > password" > feature. >=20 > =20 >=20 > The problem with just implementing this into 1.5.. its no so > straightforward, you need to fix data for existing passwords as well. >=20 > =20 >=20 > - Jonathan =20 =20 =20 =20 ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel =20 =20 =20 =20 ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel =20 =20 =20 ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel =20 =20 =20 =20 ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel =20 =20 =20 ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel =20 =20 =20 =20 ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel =20 =20 =20 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dick _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel |
From: William F. <WF...@im...> - 2005-04-02 17:39:00
|
This said, I have plans for windows apps later and implementing things = like your chat application in key areas. The underlying framework = should be geared toward the data and getting at it, not the UI it is = connected to. The UI could be a web service or a web browser or even an = admin sitting at the server console. We should plan for all these and = do the most popular first... =20 ________________________________ From: rai...@li... = [mailto:rai...@li...] On Behalf Of = Jonathan Minond Sent: Saturday, April 02, 2005 6:45 AM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security =20 I understand everything you are saying about the encryption and hashing. = I don't think we have a disagreement here.... passwords should be = hashed... two way though unless I am still not understanding means = windows apps... or things installed on client. You can hash it in = Javascript or whatever before sending, which is one thing, but like you = said once it's hashed, it's hashed, no going back.=20 I still don't like the idea of planning anything around window apps or = anything that requires users to install things. You can build a wealth = of services that can use window apps, to create applications for = controlling content, manipulating data in db, etc... but in the end, RB, = 1.5 and 1.6 are meant to server up content anywhere anytime to anyone, = as well as the main administration must also be online.=20 Added value apps that would make use of services provided to deal with = the data are one thing, for example you mentioned a chat... chat should = be browser... not window app...this is my opinion. Windows apps will not = replace the browser in any way, any time soon. As far as speed, it's a = matter of connections and bandwidth, not browser limitations. People = will want to shop online, not install the stores window app to buy their = products, people want to chat online, not install chat software that = communicates with whatever chat server. Anyway, I feel like I am going in a circle on this one.... I liked your = solution to passwords, with password secret and multiple keys to get at = the password and I feel that this should begin to get moved on = immediately starting with 1.5 and including the solution in 1.6 using = the user profiles ( reminder we need to make to spec out the solution = properly so bill can add the required fields to the user tables ) are = you taking the lead in implementing this for 1.5 and guiding the process = to 1.6? I am not sure I fully understand what your solution for 2 way encryption = on the data is. I'll accept anything that leaves your solution to the = browser... because that is the main goal I believe. User enters item = data online, it gets encrypted, stored in db, then if authorized he can = view it devrypted. Do this on the browser without installing any window = apps, java applets, activeX or anything and then we have a solution that = is cross browser and I believe will be accepted by everyone. Don't = forget you must rely on the portal/site/module/item setting that even = decides if said data is even encrypted.=20 =20 =20 -----Original Message----- From: rai...@li... = [mailto:rai...@li...] On Behalf Of = Jeffrey MRA Sent: Friday, April 01, 2005 8:42 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security =20 I think it was late last night when I wrote this; what I meant was that = ASP 2.0 Window Apps will make this kind of secure communications that is = being done in browsers now posse; not that web sites in general; effected web sites will be Chat and other two way encrypted communications; this is because of the ease of deploying Windows apps and doing live updates and = the speed gained by using them over a browser that doesn't leaned itself = well to this. =20 I was referring to running C# in scripts just like java scripts; but = using .Nets built in encryption. There are many choices in encryption; some = are better suited for some needs than others; some are over kill; others are slower; but all of them depend on the type of data being encrypted. One thing to think about is custom compression functions with encryption; = this would improve the transmission speed. I chose this function because of = ease of use and speed; by using a define statement you can bench mark each = method or make it and if statement and allow the admin to chose method; keep in mind that you can't switch on the fly once you save a format to the = database without using the original method to decrypt it. Storing encrypted data is no deferent than any other data with one exception; control characters; I found one method of encryption that had = a nasty habit of using the "'" tick character that causes run time errors = if not handled correctly; I have found it better to use the StringValue.Replace("'","'"); as part of saving any data to SQL; it = doesn't (doesn't) change the use of the character and most people don't ever = notice it; but you can't do this with encrypted data; in fact you have to make = sure that you are not changing the data at all during the save and retrieve operation; this may sound like a given but I find that HTML optimization = is used a lot in saving data to the database and this would corrupt = encrypted data; this is one reason why I say the hash function I submitted is the = only option for passwords; it makes it easy to determine if it is encrypted = using a Regular Expression since the format will never change; whereas other methods would make it impossible to tell encrypted data from clear text; also keep in mind that this type of hash data is not an encryption = method at all; in fact you can't get the original password out of the hash data; = all you can do is compare the value of one hashed password to the stored = value; which is the whole point to password security; don't store the password = at all; thus stating there are other encryption methods like MD5, SHA128... = is missing this point entirely. =20 Jeff Flesher =20 -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jonathan Minond Sent: Friday, April 01, 2005 1:19 AM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security =20 1.6 is still .net 1.1 The permission system is like that of NTFS, ( we will still need to come = up with comfortable ui's and admins for this ) Modules are a good place to move to .net 2 Skins we prefer zen2...if we can can get it ;-) =20 Also 1.1 although built with services in mind... and is still meant for browser. So NO thining the target market please :-) I don't think web = sites will become pass=E9 because of 2.0... personally I don't like installing = a bunch of things.... End users will not want to install programs just so = they can visit one site.. even if it is a rainbow site ;-) It is = unrealistic... at least in the near future. So you have to keep the solutions to things that function on browser. I don't know what you mean by c# running on the browser....client side? Unless you meant in a windows app. I have used javascript for encrypt/decrypt before, but as you said it's = a little bit limited.=20 If we are looking to encrypt content Items you mentioned TripleDES or Rijndael ... can you elaborate a little on the whole process of storing = the encrypted items in db We need super fast runtime encryption/decryption of the data. The data = still hits the client ( if approved content, since content ahs permissions, assuming all contnetn has default anonymous allowed, but portal admin = chose to encrypt data in db )...then this data can be served to anyone using = the proper channel... a module or whatever, just not hacking the DB... The other factor is that permissions are hierarchy, so we get big performance considerations there. You need to check things on=20 =20 a) Portal -> page -> module -> ContentItem ( Then if module has = attachments) You have to continue checking all the attachments to make sure they have rights to see them. This could potentially become a long running strech = if we are not careful. =20 =20 =20 =20 =20 -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jeffrey MRA Sent: Friday, April 01, 2005 9:49 AM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security =20 Read my last reply before this one please. ASP 2.0 has some very good features; are we talking about using any of = them or making new ones? I'd opted to roll my own if security is really and = issue and if you are going to spend a lot of CPU time then it better be. Now I have to look at two cases here so for argument sakes I'm going to assume that we talking about 1.6 and ASP 2.0 and make one rule; that = this is going to be a secure communication as we can for the effort; CPU time is = a premium it can make or break your site; load factors and farming all = factor in; I have an ideal solution I have used for years and it will work even better with ASP 2.0; Windows Applications... What this is a web site you say; ASP 2.0 makes Window apps live update feature so easy web sites my become posse; you simple write a Windows app to use your SQL server and = then all your CPU time is on the client end and the encryption isn't done via = a browser at all but in the Windows Application; this runs in Mono LAN so Linux users can breath again; even MAC will be able to run these new C# Window apps; in fact you can do the whole web site in a Windows app. Now the second case:=20 Encryption of large amounts of data is time consuming; keep in mind = there are many ways to do this; I still like the three key system; but with a twist from the last one I described; public is given to all authorized users; private is the users log on password and fixed is again for the portal. Client side decryption can be done using C# or JAVA script = (Limited) or signed JAVA classes (Expensive and Limited); I would use C# even = though you might limit your target base; always a trade off. Hash is out of the question for data content; TripleDES or Rijndael are both good; the = first is faster from my test but the second more secure. You hash the three keys together to make a password for the following. public static void Encrypt(string fileIn, string fileOut, string = password)=20 {=20 if (password =3D=3D null) return; if (password.Trim().Length =3D=3D 0) return; // First we are going to open the file streams=20 FileStream FileStreamIn =3D new FileStream(fileIn, FileMode.Open, FileAccess.Read);=20 FileStream FileStreamOut =3D new FileStream(fileOut, = FileMode.OpenOrCreate, FileAccess.Write);=20 // Then we are going to derive a Key and=20 // an IV from the Password and create an algorithm=20 PasswordDeriveBytes ThisPasswordDeriveByte =3D new PasswordDeriveBytes(password, new byte[] {0x49, 0x76, 0x61, 0x6e, 0x20, 0x4d, 0x65, 0x64, 0x76, 0x65, 0x64, 0x65, 0x76});=20 #if (UseTripleDES) TripleDES CryptoAlgorithm =3D TripleDES.Create();=20 CryptoAlgorithm.Key =3D ThisPasswordDeriveByte.GetBytes(16);=20 CryptoAlgorithm.IV =3D ThisPasswordDeriveByte.GetBytes(8);=20 #endif #if (UseRijndael) Rijndael CryptoAlgorithm =3D Rijndael.Create();=20 CryptoAlgorithm.Key =3D ThisPasswordDeriveByte.GetBytes(32);=20 CryptoAlgorithm.IV =3D ThisPasswordDeriveByte.GetBytes(16);=20 #endif // Now create a crypto stream through which we are going to be pumping = data. =20 // Our fileOut is going to be receiving the encrypted bytes.=20 CryptoStream ThisCryptoStream =3D new CryptoStream(FileStreamOut, CryptoAlgorithm.CreateEncryptor(), CryptoStreamMode.Write);=20 // Now will will initialize a Buffer=20 // and will be processing the input file in chunks.=20 // This is done to avoid reading the whole file=20 // (which can be huge) into memory.=20 int BufferLen =3D 4096;=20 byte[] Buffer =3D new byte[BufferLen];=20 int BytesRead;=20 do=20 {=20 // read a chunk of data from the input file=20 BytesRead =3D FileStreamIn.Read(Buffer, 0, BufferLen);=20 // encrypt it=20 ThisCryptoStream.Write(Buffer, 0, BytesRead);=20 } while(BytesRead !=3D 0);=20 // close everything=20 // this will also close the unrelying FileStreamOut stream ThisCryptoStream.Close();=20 FileStreamIn.Close(); =20 } =20 =20 public static void Decrypt(string fileIn, string fileOut, string = password)=20 {=20 if (password =3D=3D null) return; if (password.Trim().Length =3D=3D 0) return; // First we are going to open the file streams=20 FileStream FileStreamIn =3D new FileStream(fileIn, FileMode.Open, FileAccess.Read);=20 FileStream FileStreamOut =3D new FileStream(fileOut, = FileMode.OpenOrCreate, FileAccess.Write);=20 // Then we are going to derive a Key and=20 // an IV from the Password and create an algorithm=20 PasswordDeriveBytes ThisPasswordDeriveByte =3D new PasswordDeriveBytes(password, new byte[] {0x49, 0x76, 0x61, 0x6e, 0x20, 0x4d, 0x65, 0x64, 0x76, 0x65, 0x64, 0x65, 0x76});=20 #if (UseTripleDES) TripleDES CryptoAlgorithm =3D TripleDES.Create();=20 CryptoAlgorithm.Key =3D ThisPasswordDeriveByte.GetBytes(16);=20 CryptoAlgorithm.IV =3D ThisPasswordDeriveByte.GetBytes(8);=20 #endif #if (UseRijndael) Rijndael CryptoAlgorithm =3D Rijndael.Create();=20 CryptoAlgorithm.Key =3D ThisPasswordDeriveByte.GetBytes(32);=20 CryptoAlgorithm.IV =3D ThisPasswordDeriveByte.GetBytes(16);=20 #endif // Now create a crypto stream through which we are going to be pumping = data. =20 // Our fileOut is going to be receiving the Decrypted bytes.=20 CryptoStream ThisCryptoStream =3D new CryptoStream(FileStreamOut, CryptoAlgorithm.CreateDecryptor(), CryptoStreamMode.Write);=20 // Now will will initialize a Buffer=20 // and will be processing the input file in chunks.=20 // This is done to avoid reading the=20 // whole file (which can be huge) into memory.=20 int BufferLen =3D 4096;=20 byte[] Buffer =3D new byte[BufferLen];=20 int BytesRead;=20 do=20 {=20 // read a chunk of data from the input file=20 BytesRead =3D FileStreamIn.Read(Buffer, 0, BufferLen);=20 // Decrypt it=20 ThisCryptoStream.Write(Buffer, 0, BytesRead);=20 } while(BytesRead !=3D 0);=20 // close everything=20 ThisCryptoStream.Close(); // this will also close the unrelying FileStreamOut stream=20 FileStreamIn.Close(); =20 } I never tried this in a client code; but if C# code truly can run client side this should work; by the way these are very good functions I hope = you enjoy them as much as I did. As far as links go a search engine would drive me crazy answering a = question I already know; I could find worse sources of info and some might think better; but I say if it works good use it; it's simple and proven the = key is in the keys; three keys: public, private and fixed; how much more secure = to do need it? =20 Jeff Flesher =20 -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jonathan Minond Sent: Thursday, March 31, 2005 11:31 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security =20 Also... One of the plans in 1.6 is that almost everything is encryptable,=20 Meaning you can encrypt all your data from content not just passwords = :-) But this is all server side so far....=20 Can you provide some links on acceptable 2 way hash solutions? =20 -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jeffrey MRA Sent: Friday, April 01, 2005 4:21 AM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security =20 I don't agree with it being a performance issue; we are talking about = one field here; not many users have passwords with more than 10 characters; = what are we talking about is microseconds of computer CPU time. There is no software to install with the function I included; nor is there a reason = to use or offer to use more than one option for encryption; overkill.=20 As far as changing the database; it is not need; check to see if the password is in clear text; if so use it; if not then use the encryption method; keep it simple (KISS). This is not rocket science it's the = ability to encrypt passwords to make a secure or more secure system.=20 I will also disagree as that sending password reminder is a good thing; = it's not; in fact it is a serious security birch; at least with a password = reset you can add a traceable element to the transaction; keep in mind if = someone stills your email and than ask for a password and as is you just hand it out; this happens all the time; I know that not to long ago someone here = had their email stolen; now what if they used it to hack his web site?=20 I believe fully in security and all I'm suggesting is the bare minimum; = but your right; we need to explore all options and let everyone let there = option known; I value your option but I ask you to error on the side of good judgment; in other words come up with a good argument. Ask yourself what = you think a customer wants; as programmers we some things get myopic and = can't see the obvious; if this is an e-commerce site (and I think it is or can = be) then where is the security? I can come up with far too many arguments = for security and none for not having any; that's just my option and all most = 30 years as a computer programmer.=20 =20 Jeff Flesher =20 -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Jonathan Minond Sent: Thursday, March 31, 2005 2:24 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security =20 Would that not require end users to install extra things beyond a = browser? Like an email client with that supports is, or some way to manage the = key? Seems like it gets complicated. Maybe something to consider as one of = the options for 1.6. We can technically offer sever options, that are Site = or Portal admin defined.=20 As a default for the application I wouldn't suggest it. I suggest = default is simple hash with a new password generator. Then a user can log in and = edit their profile and password again. Why don't we get a list of the options? And then maybe we can start = looking at how to handle this. We also don't want to go to crazy... letting = people have so many options. I think standard are=20 Clear text MD5 SHA128 SHA256 SHA512 Etc... Anything over 256 is already costing a lot performance wise, but I = suppose if you want to potentially have rainbow support enterprise, and economic type systems you need to offer high end...=20 I don't think any of this is a rush decisions, but we should get a list = of options that people agree rb should support. My opinion is that we = should not force end users to rely much on extra things beyond the browser as = far as core features are concerned. =20 - Jonathan =20 -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of = Pekka Ylenius Sent: Thursday, March 31, 2005 10:34 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security =20 =20 How about 2way encryption... It is possible to return password but it is not clear text. =20 =20 -----Original Message----- From: "Jonathan Minond" <jon...@jo...> To: <rai...@li...> Date: Thu, 31 Mar 2005 21:16:29 +0200 Subject: RE: [Rainbowportal-devel] Security =20 > Clear text offeres >=20 > 1) password remindes >=20 > 2) Less security =3D more performance >=20 > =20 >=20 > The more you hash and secure things, the slower they will be. however > this > is not sucha worry for just logins. >=20 > And instead of password reminder you can offer a "Generate new > password" > feature. >=20 > =20 >=20 > The problem with just implementing this into 1.5.. its no so > straightforward, you need to fix data for existing passwords as well. >=20 > =20 >=20 > - Jonathan =20 =20 =20 =20 ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel =20 =20 =20 =20 ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel =20 =20 =20 ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel =20 =20 =20 =20 ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel =20 =20 =20 ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel =20 =20 =20 =20 ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel =20 =20 =20 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dick _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel |
From: Jonathan M. <jon...@jo...> - 2005-03-31 19:16:40
|
Clear text offeres 1) password remindes 2) Less security = more performance The more you hash and secure things, the slower they will be. however this is not sucha worry for just logins. And instead of password reminder you can offer a "Generate new password" feature. The problem with just implementing this into 1.5.. its no so straightforward, you need to fix data for existing passwords as well. - Jonathan _____ From: rai...@li... [mailto:rai...@li...] On Behalf Of Jeffrey MRA Sent: Thursday, March 31, 2005 8:31 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security I agree that this should be added as an option; I would suggest putting an entry in the Web.Config file. I would like to know what advantages there are in a clear text database for passwords? The only one I can think of is sending a user a forgotten password; which in itself is a bad idea from a security point. I beta testing I can see this; that's the one reason I agree to make it an option; the other being I don't want to force anyone into using a feature they don't need or want. I look at this from a damage control security stance; anyone with admin rights (not to mention hackers) can use the Database tool to run a query against the user database and list all the passwords for all the portals; then in turn use this user names and passwords to log in and change content in a very malicious way if they wanted; and the changes would reflex the end users log on info that was stolen; even though the IP address wouldn't; this is little consequence on a corporate web site and could be a major embarrassment at least and financial disaster or worse. I understand that 1.6 will have a better security solution; this was just a hack to hold us over. Jeff Flesher _____ on 31/03/2005 7:44 Jeffrey MRA said the following: I don't like the clear text passwords in the database from a security point; I hope we all can agree on that. I don't want be be a pain, but I hope that encrypted password will be an option, a default option maybe, but still an option. Because having them not encrypted has proven us very usefull in several cases. Rob I suggest adding this function to the Security class; it is the same function used in the Portals Starter Kit which was the successor to IBS Portal. public static string Encrypt(string cleanString) { Byte[] ClearBytes = new UnicodeEncoding().GetBytes(cleanString); Byte[] HashedBytes = ((HashAlgorithm) CryptoConfig.CreateFromName("MD5")).ComputeHash(ClearBytes); return BitConverter.ToString(HashedBytes); } // end Encrypt Call to string EncrptedPassword = Encrypt(password); Such that password will return something like D0-09-1A-0F-E2-B2-09-34-D8-8B-46-06-84-F5-97-89 Much more secure since you can't take this value and log on with it since it is the original password that produces this hash code. Somewhere in the code Add it to the code app_code -> Security -> Security.cs Around line 441 public static string SignOn(string user, string password, bool persistent, string redirectPage) which in turn gets executed in app_code -> Rainbow -> DAL -> UsersDb.cs Around line 994 public Rainbow.Security.User Login(int uid, string password, int portalID) I do realize that we'll have to do a reset password instead of a "I forgot my password" option. Jeff Flesher |
From: Pekka Y. <pe...@pr...> - 2005-03-31 20:19:21
|
How about 2way encryption... It is possible to return password but it is not clear text. -----Original Message----- From: "Jonathan Minond" <jon...@jo...> To: <rai...@li...> Date: Thu, 31 Mar 2005 21:16:29 +0200 Subject: RE: [Rainbowportal-devel] Security > Clear text offeres > > 1) password remindes > > 2) Less security = more performance > > > > The more you hash and secure things, the slower they will be. however > this > is not sucha worry for just logins. > > And instead of password reminder you can offer a "Generate new > password" > feature. > > > > The problem with just implementing this into 1.5.. its no so > straightforward, you need to fix data for existing passwords as well. > > > > - Jonathan |
From: Jonathan M. <jon...@jo...> - 2005-03-31 22:25:04
|
Would that not require end users to install extra things beyond a browser? Like an email client with that supports is, or some way to manage the key? Seems like it gets complicated. Maybe something to consider as one of the options for 1.6. We can technically offer sever options, that are Site or Portal admin defined. As a default for the application I wouldn't suggest it. I suggest default is simple hash with a new password generator. Then a user can log in and edit their profile and password again. Why don't we get a list of the options? And then maybe we can start looking at how to handle this. We also don't want to go to crazy... letting people have so many options. I think standard are Clear text MD5 SHA128 SHA256 SHA512 Etc... Anything over 256 is already costing a lot performance wise, but I suppose if you want to potentially have rainbow support enterprise, and economic type systems you need to offer high end... I don't think any of this is a rush decisions, but we should get a list of options that people agree rb should support. My opinion is that we should not force end users to rely much on extra things beyond the browser as far as core features are concerned. - Jonathan -----Original Message----- From: rai...@li... [mailto:rai...@li...] On Behalf Of Pekka Ylenius Sent: Thursday, March 31, 2005 10:34 PM To: rai...@li... Subject: RE: [Rainbowportal-devel] Security How about 2way encryption... It is possible to return password but it is not clear text. -----Original Message----- From: "Jonathan Minond" <jon...@jo...> To: <rai...@li...> Date: Thu, 31 Mar 2005 21:16:29 +0200 Subject: RE: [Rainbowportal-devel] Security > Clear text offeres > > 1) password remindes > > 2) Less security = more performance > > > > The more you hash and secure things, the slower they will be. however > this > is not sucha worry for just logins. > > And instead of password reminder you can offer a "Generate new > password" > feature. > > > > The problem with just implementing this into 1.5.. its no so > straightforward, you need to fix data for existing passwords as well. > > > > - Jonathan ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ Rainbowportal-devel mailing list Rai...@li... https://lists.sourceforge.net/lists/listinfo/rainbowportal-devel |
From: HolonCom S. <su...@ho...> - 2005-04-01 07:10:45
|
on 31/03/2005 20:31 Jeffrey MRA said the following: > I agree that this should be added as an option; I would suggest=20 > putting an entry in the Web.Config file. > > I would like to know what advantages there are in a clear text=20 > database for passwords? > As a work around for the fact that, as an administrator, you can't=20 imporsonate a user who complains about a bug so you are able to see what=20 is actually happening. And there are still some bugs in rainbow ;-) So requesting a new password =E0nd encrypting - although this would indee= d=20 be the best design - it would make this even more difficult. But I'm sure a solution for this could be found. To summerize, best design imho would be: - encrypted passwords - request for new password instead of send password when forgotten - means for an administrator to impersonate a user (although I even=20 would like the concept of an SystemAdmin that only could do dangerous=20 things like this) Rob |
From: matro <ma...@re...> - 2005-04-03 00:58:53
|
I vote - if a vote is accepted :) - for an implementation on rb 1.5 of password encryption as Jeffrey proposed (with the if for existing clear passwords and the enabling option in the web.config). =20 I know the line is not to develop new things on 1.5, but I think that pw encryption is an important topic, easy to implement and isolated to the Security type only. _____=20=20 Da: rai...@li... [mailto:rai...@li...] Per conto di Jeffrey MRA Inviato: gioved=EC 31 marzo 2005 20.31 A: rai...@li... Oggetto: RE: [Rainbowportal-devel] Security I agree that this should be added as an option; I would suggest putting an entry in the Web.Config file. I would like to know what advantages there are in a clear text database for passwords? The only one I can think of is sending a user a forgotten password; which in itself is a bad idea from a security point. I beta testing I can see this; that=92s the one reason I agree to make it an option; the other being I don=92t want to force anyone into using a feature they don=92t need or want. I look at this from a damage control security stance; anyone with admin rights (not to mention hackers) can use the Database tool to run a query against the user database and list all the passwords for all the portals; then in turn use this user names and passwords to log in and change content in a very malicious way if they wanted; and the changes would reflex the end users log on info that was stolen; even though the IP address wouldn=92t; t= his is little consequence on a corporate web site and could be a major embarrassment at least and financial disaster or worse.=20 I understand that 1.6 will have a better security solution; this was just a hack to hold us over.=20=20=20=20=20 =20 Jeff Flesher -------- Francesco "Matro" Martire RealPopup <http://www.realpopup.it> , the freeware winpopup replacer RealAccount <http://www.realpopup.it/realaccount> , freeware plugin for MS Outlook |