I have a Tabular User Maintenace Window that uses Datawindow Select / Update.
I need to encrypt the password saved on the MSSQL Database.
I have a function f_decrypt for Powerbuilder and for dbo.
How can I use dw.Update() to encrypt the password?
A small book could probably be written on the possibilities. My first question is the requirement to store encrypted passwords, or does the password have to go over the wire encrypted. If storage is the only requirement, I'd tend to let the DBMS do what a team of high level programmers spent months trying to get right, rather than to try to reinvent the wheel myself. Even if it has to go over the wire encrypted, I'd look at DBMS-provided options first.
If you have to do it client-side and deal with hashing, salting, preventing reverse engineering of your code, et al, yourself, there are still probably a dozen ways to do it. The first way I'd try is to make a DataWindow with a dummy column for the password user interface, as well as the column in the table, e.g.
SELECT ' ' as password_ui,
table.password_storage,
...
FROM table
....
I'd put password_ui on the DataWindow's user interface, and leave password_storage off the user interface, but make sure password_storage is included in the Update Properties as an updatable column. Then, on ItemChanged, if the column changed is password_ui, I'd
CHOOSE CASE dwo.Name
CASE "password_ui"
SetItem (row, "password_storage", f_encrypt (data))
END CHOOSE
Good luck,
Terry.
Related
I am scanning my web application which i have build in Asp.net. Scanner is injecting junk data into the system trying to do blind Sql injection on the system but i am using Sql store procedures with parametrized quires which is escaping the blind sql injection but these junk entries are stored into the system as normal text i am sanitizing the inputs not to take ' and other sql related parameters.Now my question are
1) Are these junk entries any threat to the system?
2) Do i really need to sanitize the input if i am already using paramitrised quires with store procedures?
3) Scanner is not able to enter information into the system if u don't create login sequence is that a good thing?
Any other precautions i should take please let me know
Thanks
As you correctly mentioned, the 'junk' entries in your database are form submissions that Acunetix is submitting when testing for SQL injection, XSS and other vulnerabilities.
To answer your questions specifically:
1) No, this junk data is just an artifact of the scanner submitting forms. You might want to consider applying stricter validation on these forms though -- remember, if a scanner can input a bunch of bogus data, an automated script (or a real user for that matter) can also insert a bunch of bogus data.
Some ideas for better validation could include restricting the kind of input based on what data should be allowed in a particular field. For example, if a user is expected to input a telephone number, then there is no point allowing the user to enter alpha-characters (numbers, spaces, dashes, parenthesis and a plus sign should be enough for a phone number).
Alternatively, you may also consider using a CAPTCHA for some forms. Too many CAPTCHAs may adversely affect the user experience, so be cautious where, when and how often you make use of them.
2) If you are talking about SQL injection, no, you shouldn't need to do anything else. Parameterized queries are the proper way to avoid SQLi. However, be careful of Cross-site Scripting (XSS). Filtering characters like <>'" is not the way to go when dealing with XSS.
In order to deal with XSS, the best approach (most of the time) is to exercise Context-dependent Outbound Encoding, which basically boils-down to -- use the proper encoding based on which XSS context you're in, and encode when data is printed onto the page (i.e. do not encode when saving data to the database, encode when you are writing that data to the page). To read more about this, this is the easiest, and most complete source I've come across -- http://excess-xss.com/#xss-prevention
3) A login sequence is Acunetix's way of authenticating into your application. Without it, the scanner can not scan the internals of your app. So unless you have forms (perhaps on the customer-facing portion of your site) the scanner is not going to be able to insert any data -- Yes, this is generally a good thing :)
I am working on an asp.net application where one of the security requirements is that the application must enfore "password history" - (remember previous 8 passwords).
I would like to know if someone has an experience designing a table (using SQL 2008) for this purpose. So far, I am thinking of just having one table, and one field per previous password and one field for the date of the password.
Any other suggestions / best practices?
I would create a password history table just for storing the old passwords, salted and hashed of course. This is a classic one to many relationship, having 8 fields for 8 different old passwords seems brittle.
You can store the date of each historical password with it in the password history table for aging out when they have changed the password more than 8 times.
Your suggestion sounds fine, but I would recommend storing salted hashes of the password instead. You'd either need to keep the salt constant per user and store it on the user table, or store it with the previous password entry if you want to refresh the salt each time the password is changed. The first option makes for the simplest database query to check previous passwords - the latter you'll have to do each comparison individually.
Remember to implement a rate limit on the password changes. My experience suggest that users will find out if there is none and will change password 9 times in a row to end up with the old one if you leave that chance...
Other best practices really depend on how secure you want the system to be. One thing I've seen doing, for instance, is trying a 10 seconds bruteforcing using the new password as a seed (for existing tools) or with basic iteration. i.e. if you see a password in the form of foobar5, try to see if foobar1/2/3/4 match any of the old hashes.
I was hoping someone could help me sort something out. I've been working on a shopping cart plugin for WordPress for quite a while now. I started coding it at the end of 2008 (and it's been one of those "work on it when I have time" projects, so the going is very slow, obviously!) and got pretty far with it. Even had a few testers take me up on it and give me feedback. (Please note that this plugin is also meant to be a fee download - I have no intention of making it a premium plugin.)
Anyway, in 2010, when all the PCI/DSS stuff became standard, I shelved it, because the plugin was meant to retain certain information in the database, and I was not 100% sure what qualified as "sensitive data," and I didn't want to put anything out there that might compromise anyone, and possibly come back on me.
Over the last few weeks, some colleagues and I have been having a discussion about PCI/DSS compliance, and it's sparked a re-interest in finally finishing this plugin. I'm going to remove the storage of credit card numbers and any data of that nature, but I do like the idea of storing the names and shipping addresses of people who voluntarily might want to create an account with the site that might use this plugin so if they shop there again, that kind of info is retained. Keep in mind, the data stored would be public information - the kind of thing you'd find in a phone book, or a peek in the record room of a courthouse. So nothing like storing SS#'s, medical histories or credit card numbers. Just stuff that would maybe let someone see past purchases, and retain some info to make a future checkout process a bit easier.
One of my colleagues suggested I still do something to enhance security a bit, since the name and shipping address would likely be passed to whatever payment gateway the site owner would choose to use. They suggested I use "one-way encryption." Now, I'm not a huge security freak, but I'm pretty sure this involves (one aspect anyway) stuff like MD5 hashes with salts, or the like. So this confuses me, because I wouldn't have the slightest idea of where to look to see how to use that kind of thing with my code, and/or if it will work when passing that kind of data to PayPal or Google Checkout, or Mal's, or what have you.
So I suppose this isn't an "I need code examples" kind of question, but more of a "please enlighten me, because I'm sort of a dunce" kind of question. (which, I'm sure, makes people feel much better about the fact that I'm writing a shopping cart plugin LOL)
One way encryption is used to store information in the database that you don't need back out of the database again in its unencrypted stage (hence the one-way moniker). It could, in a more general sense, be used to demonstrate that two different people (or systems) are in possession of the same piece of data. Git, for instance, uses hashes to check if files (and indeed entire directory structures) are identical.
Generally in an ecomm contect hashes are used for passwords (and sometimes credit cards) because as the site owner, you don't need to retain the actual password, you just need a function to be able to determine if the password currently being sent by the user is the same as the one previously provided. So in order to authenticate a user you would pass the password provided through the encryption algorithm (MD5, SHA, etc) in order to get a 'hash'. If the hash matches the hash previously generated and stored in the database, you know the password is the same.
WordPress uses salted hashes to store it's passwords. If you open up your wp_users table in the database you'll see the hashes.
Upside to this system is that if someone steals your database, they don't get the original passwords, just the hash values which the thief can't then use to log in to your users' Facebook, banking, etc sites (if your user has used the same password). Actually, they can't even use the hashes to log in to the site they were stolen from as hashing a hash produces a different hash.
The salt provides a measure of protection against dictionary attacks on the hash. There are databases available of mappings between common passwords and hash values where the hash values have been generated by regularly used one way hash functions. If, when generating the hash, you tack a salt value on to the end of your password string (eg my password becomes abc123salt), you can still do the comparison against the hash value you've previously generated and stored if you use the same salt value each time.
You wouldn't one way hash something like an address or phone number (or something along those lines) if you need to use it in the future again in its raw form, say to for instance pre-populate a checkout field for a logged in user.
Best practices would also involve just not storing data that you don't need again in the future, if you don't need the phone number in the future, don't store it. If you store the response transaction number from the payment gateway, you can use this for fraud investigations and leave the storage of all of the other data up to the gateway.
I'll leave it to others to discuss the relative merits of MD5 vs. SHA vs ??? hashing systems. Note, there's functions built in to PHP to do the hashing.
I use asp membership in application.
I added UserProfile table and it has foreign key to Users(of asp membership).
As a foreign key I use Username because username is email and it's unique.
And anywhere where I need to reference user I use Username as foreign key.
From application when I need to get profile for example I pass Username to stored procedure to get data.
I just wonder if this is the good way to do this. Is there some potentional security issue here?
The main issue that I see here is that you spend a lot of "data space" for a foreign key and this will make it slow and eat database space for your tables. Also you database table will connect making string compare - database take care and make hash for this strings and behind is make a number compare, but have a little small overhead on that.
Just make the UserName unique and use a number foreign key to connect it with the rest table.
The second issue here is when a user need to change their email, or give it wrong for any reason. In this case you need to update all the connections on the database and make sure that there is not other similar email.
And one more issue is that the email and the foreign key can be case sensitive or not. If for any reason you make it case sensitive then you make a mess.
About security issues, you always need to open and ask your database using parameters. This is the same for a number key or for a string key, so this make no different at this case.
I would say no for one simple reason: many systems allow users to change their usernames. In your case, you link this to an email address, which users should be allowed to change.
If you use it as a foreign key, you have to run updates to keep your data in sync, and that is bad.
This is an old natural vs. surrogate key discussion. There are "fans" of either approach, but the simple truth is that both have pros and cons, and you'll have to make your own decision that best fits your particular situation.
For the specific case of e-mail as PK, you might want to take a look at this discussion.
Can anybody detail some approach on how to save private data in social websites like facebook, etc. They cant save all the updates and friends list in clear text format because of privacy issues. So how do they actually save it?
Hashing all the data with user password so that only a valid session view it is one possibility. But I think there are some problem with this approach and there must be some better solution.
They can and probably do save it in plain text - it goes into a database on a server somewhere. There aren't really privacy issues there... and even if there were, Facebook has publicly admitted they don't care about privacy.
Most applications do not encrypt data like this in the database. The password will usally be stored in a salted hash, and the application artchitecture is responsible for limiting visibility based on appropriate rights/roles.
Most websites do in fact save updates and friends list in clear text format---that is, they save them in an SQL database. If you are a facebook developer you can access the database using FQL, the Facebook Query Language. Queries are restricted so that you can only look at the data of "friends" or of people running your application, or their friends, or what have you. (The key difference between SQL and FQL is that you must always include a WHERE X=id where the X is a keyed column.)
There are other approaches, however. You can store information in a Bloom filter or in some kind of hash. You might want to read Peter Wayner's book Translucent Databases---he goes into clever approaches for storing data so that you can detect if it is present or missing, but you can't do brute force searches.