I'm being assigned to maintain an Advantage-based Clipper program. I tried to use Advantage Data Architect program to connect to the database, but failed. I'm thinking the password I got is wrong... maybe the previous maintainer or somebody else changed it... (it worked on the test server but not on the live server).
So I'm just wondering if it's possible to reset the password without reinstall & lose all the data?
Thanks.
Advantage website states:
ADSSYS
"All Advantage data dictionaries contain an administrative user called ADSSYS. This user has permissions to perform any operation or update on the dictionary. Be aware that if the ADSSYS password is lost, it cannot be recovered or reset."
NOTE: When the ADSSYS account is created, by default the password is blank; so you may first attempt to leave the password blank.
I suggest contacting Advantage and asking them for the resolution; as this situation has likely occurred before (and will occur again).
Related
My question is very clear. I need save some sensitive static data. For example, the url of my service or a password of encrypt. Now I have the next doubt: Is secure save this data in Localizable.strings?
No. A malicious user can easily see this in the IPA of an iTunes backup. But the user can also see this in any file in your app bundle. You will need to encrypt the string somehow. The tricky part is to hide the key as well: it may be a good idea to calculate the key somehow (you can be creative here).
Also pay attention to secure your transmission: if you would be using plain HTTP anyone who can use Wireshark would be able to see your sensitive information. Make sure you've set up HTTPS correctly and that you are validating the certificate of the server on connect (search StackOverflow about that).
I totally agree with #DarkDust. Just to add more things:
A malicious user can see the data because he does the jailbreak on one of the devices. Then he installs the app and may get whole contents of the app. He may change some code and run it.
Whole process of getting the data is called reverse engineering. It's quite wide branch and it's good to know the basics if you care about data security.
You may read more about reverse engineering at e.g. this free book: https://github.com/iosre/iOSAppReverseEngineering.
The best hacker always gets the data, it's just the matter of time. For you, as a developer, the task is to forbid getting the data for less experienced "hackers".
To make things more difficult, you can obfuscate the data.
If you need to save some credentials in app (eg login token), always use the keychain, never any other storage.
I understand that when we use MVC, once we get the user password. It should go through some layers till it is ready to be introduced to the database. So, should we encrypt the password immediately after I got it from the web form? or I can wait to encrypt the password on the database?
I do apologize if this is an stupid question, but Im just starting on this.
This might be a good starting point for reading on the topic: https://crackstation.net/hashing-security.htm. As others have mentioned, I highly recommend that you don't reinvent the wheel of security. Use existing libraries, and try to understand the process before writing any code.
To answer your question directly: If the person is creating a new account/password, I would immediately hash the password upon receiving it and store it in the database. There probably wouldn't be any 'in-between' steps. No real reason for their password (hashed or otherwise) to float around the application. Make sure to follow the principles outlined in the article that I provided, though.
Not covered in that topic: make sure to also implement SSL/TLS. This is another topic that will require some reading. I don't know where your server is located (internal to a company or publicly to the world), but people tend to use the same password for different services, and if you don't protect their passwords as it travels from the browser to the server, their password could be obtained and used with their other accounts.
In conclusion - this is a big topic that really warrants some reading before writing any code. Security is hard. Make sure to take some time to read up front and understand what needs to be done.
I have been tasked with changing the password to all service accounts within the organization, and would appreciate a few pointers from sombody who has tackled this before..
I have identified each service account- as well as each machine and service using that account. What I would like is some guidance as to how this process is actually executed. This is a production environment, and I don't want to go breaking things during work hours.
Is the process as simple/tedious as changing the service account password, then logging onto each server, locating each service and changing relevant info under the "Log on" tab?
is there a better way of doing this? Thank you for the advice/guidance.
Thats pretty much it.
What I would suggest tho is duplicating the accounts with the same permissions (but affix '2013' on the end or something) and then while you go around changing the passwords, redirect the services to that account as well.
The reason for this is that, at least a few times, some random legacy application has gone down during service account resets purely because noone knew it was using it/had missed it in the refresh/didn't know about it. This way everything you touch should be OK, and you can then monitor the now 'legacy' accounts for any use.
/edit
Actually changing the username/password CAN be scripted, but that all depends on how cautious you want to be about the change and whether you want to be able to easily halt the execution! See http://gallery.technet.microsoft.com/scriptcenter/79644be9-b5e1-4d9e-9cb5-eab1ad866eaf for an example. (You will also need to think about what range of OSs you need to do this on - PowerShell will only work on some, VBS will for the others but then you have further considerations, and NT4...... ;) )
My question is simple: How can a person access my database in production if he knows my password? I know that it can be done, because otherwise you wouldn't have to set a password for it, but I really want to know how.
Also, if someone knows the password for my database, can he execute all queries to my database (not only SELECT, but also the ones that alter the database)?
Your database is on a server, a computer just like any other. It has a MAC address, probably a NIC, and most importantly, an IP address.
If you've ever used Window's remote connection utility, you are asked for the IP address of the computer, and the login credentials for the user's account. From there, you'd open the database management system (which is simply an application running on the computer), and once you've entered the database, it's just sitting there. Just like it does for you.
The process of deleting all of your hard work, for an attacker, includes the exact same steps you would take! Pick a good password, and don't store any sensitive information on any public-facing directories on the server!
How can a person access my database in production if he knows my
password?
Through an exploit or other script where they can make a connection.
if someone knows the password for my database, can he execute all
queries to my database (not only SELECT, but also the ones that alter
the database)
They can execute whatever that account has rights to. This is a good reason that application logins only be given minimal rights. Typically in full-featured database systems, you can give the application role/account only SELECT on certain tables or views (perhaps not even all columns), and generally modify data only through stored procedures. By minimizing the surface area in this way, you have defense in depth, so not only is the account secured by a password, but the account has only a certain attack surface. This is just one part of your overall security process.
I'm making a twitter client, and I'm evaluating the various ways of protecting the user's login information.
Hashing apparently doesn't do it
Obfuscating in a reversable way is like trying to hide behind my finger
Plain text sounds and propably is promiscuous
Requiring the user to type in his password every time would make the application tiresome
Any ideas ?
You could make some OS calls to encrypt the password for you.
On Windows:
You can encrypt a file (on a NTFS filesystem)
Use the DPAPI from C
Use the DPAPI in .Net by using the ProtectedData class
CryptProtectData is a windows function for storing this kind of sensitive data.
http://msdn.microsoft.com/en-us/library/aa380261.aspx
For an example see how Chrome uses it:
http://blog.paranoidferret.com/index.php/2008/09/10/how-google-chrome-stores-passwords/
For Windows: encrypt the password using DPAPI (user store) and store it in your settings file or somewhere else. This will work on a per-user basis, e.g. different users on the same machine will have different unrelated encryption keys.
What platform?
On *nix, store the password in plain text in a file chmoded 400 in a subdirectory of the home directory. See for example ~/.subversion. Administrators can do anything they like to users anyway, including replacing your program with their own hacked version that captures passwords, so there's no harm in the fact that they can see the file. Beware that the password is also accessible to someone who takes out that hard drive - if this is a problem then either get the user to reenter the password each time or check whether this version of *nix has file encryption.
On Windows Pro, store the password in an encrypted file.
On Windows Amateur, do the same as *nix. [Edit: CryptProtectData looks good, as Aleris suggests. If it's available on all Windowses, then it solves the problem of only the more expensive versions supporting encrypted files].
On Symbian, store the password in your data cage. Programs with AllFiles permission are rare and supposedly trusted anyway, a bit like *nix admins.
You can't have your cake and eat it too. Either store the password (which you've ruled out), or don't and require it to be typed in every time (which you've ruled out.)
Have a good symmetric encryption scheme, it should make it difficult enough to decrypt the credentials that it won't worth trying.
Otherwise, if the service only requires the hash to be sent over the network, you can store the hast encrypted. This way even the decryption won't get the attacker closer to the solution.
However other users are true. If you store the data it can be found.
The key is finding the balance between security and usability.