I have to import many thousands of userdata into fe_users table. The problem is that the userdata include one-time passwords which are set elsewhere.
Is there a way to import and salt the passwords automatically?
(In former times this happened after the first login, but this seems not to be possible any more. I remember that some years ago there was a scheduler task to do this, but this seems to have disappeared, somehow?)
Any suggestion welcome.
We decided not to use the passwords. As long as the userdata contain the real email adresses, (which they do), the users can use the password-forgotten-function to set their own passwords.
Related
I have a couple of functions (login, reset-password) implemented as functions. Is it possible to make sure that these functions are not logged by either postgres itself or any extensions that may be installed?
You cannot absolutely eliminate the possibility of logging parameters. Your log files should only be readable by people you really trust (generally the same people who have superuser on the database). Also, you might consider reading the salt and hash from the database and doing the rehashing and comparison in the app server, rather than sending the password in the clear to the database.
I am looking for a mechanism for users table password field decryption or un-hash for Drupal 7. decryption is required for one of my project. this users table data need to be migrated in another system. any help will be appreciated. thanks in advance.
As of Drupal 7, there is no way to decrypt user passwords ... full stop.
For more details, refer to the answers to this question on Drupal.SE.
Concur with Pierre. Drupal 7 hashes are true hashes and therefore not 'reversible'. The original plaintexts must be known in order to verify them.
Your only other options are either:
cracking them, or
intercepting them at a low level as users successfully authenticate.
But both of these can be challenging (and even distasteful) in multiple ways, that are probably outside the scope of this question (as currently written):
technically (How will you crack them, or how will you intercept?)
security-wise (How can you keep the plaintexts safe? How will you destroy the plaintexts afterwards?)
ethically (How can you do this without disclosing user passwords to yourself?)
I would like to add simple password protection in an iPhone App that I am working on. I will probably use crypt() to store the password in my database which in in CoreData / sqlite format.
I think I have a pretty good understanding of how to create and store the password, but in case the user forgets their password, I would like to add a password recovery ability
This is the part that I'm struggling with in iOS. I want everything to be local, so I can't think of a way to use a link to reset a password.
I had thought about emailing the password, but in iOS there is no way to send emails without the person holding the device seeing the contents of the email.
The only way that I can think of is to have one or two "backup passwords" which is basically the answer to a question of the user's choice (or maybe even just storing a reminder question along with the password).
Neither of these are really that secure, although the data being protected in my app is not that critical, so I'm not looking for the most robust solution (just a decent solution that is not too hard to implement, not too inconvenient for the user, and not too hard for a hacker to break).
Suggestions are greatly appreciated.
Thanks,
Ron
Instead of recovering a password, you can prompt to reset a password using criteria that is set up when they initially create their account -- such as mothers maiden name, last-4, etc. This way, you don't need to worry about decrypting a password or sending it to the user. Once they answer enough security questions correctly, they are prompted to reset their password. You can store this data encrypted locally. You'll never need to send a password to the user.
The easiest way is probably to make "password protection" optional and display a warning ("if you forget your password, your data may be irrecoverable!").
It's not going to be that secure: The data is probably going to appear unencrypted in a phone backup, unless you encrypt it yourself. The upshot is that determined users can ask you for help, and you can write them a tool that digs through the unencrypted backup and resets the password.
Avoid the built-in crypt(), which is probably DES-based and limited to 8 ASCII characters. Storing the plaintext password in the keychain is not too terrible an option.
Is there a way to password protect the SQL Lite db core data uses for it's persistent store? I want to make the DB available via iTunes but I want to be password protected so only I can open it.
CoreData doesnt have any built in password protection so you are going to have to roll your own encryption or obfuscation mechanism.
Alternatives could be obscure mechanisms (press the invisible button three times?) to send the file by email for returning the data-store to you rather than exposing the Documents folder in iTunes.
I guess the question is there a genuine need for password protection (i.e personal/medical records) or is this just the usual Corporate paranoia. If its the latter I wouldn't put too much effort in. IMHO.
I have a customer that has an old non-existant application; he had a problem with the company that made the application and they won't disclose his database password. He realized that he signed a contract (back then) where it said that he was sort of "renting" the application and they had no right to disclose anything. This customer found out that he's not the only one with the same problem with that company. He's a Dentist and other dentists with the same old application experienced the same problems when trying to buy a new software and attempted to migrate their patients to the new system.
In either case, he wants to open his little firebird database, so we can at least extract some data to our SQL Servers. I have tried with the default 'masterkey' (which is, in fact, 'masterke' due to the 8 char limit) to no avail.
Now I know he could go legal and try to force the company to release his information, but I want to do it the short way. Does anybody know an app that can brute force/crack a legacy Firebird password?
Thanks.
EDIT: The legacy software is "STOMA-W", I cannot even find it on Internet. They are located in Asturias, Spain.
Firebird does not (yet) store passwords inside the database file.
With this in mind, move the database file to another server where the sysdba password is known.
Old Interbase and Firebird had hardcoded backdoor password you might want to try:
user: politically pass: correct
http://www.theregister.co.uk/2001/01/12/borland_interbase_backdoor_exposed
Provided not for the SYSDBA account, you may reset forgotten passwords for users with FlameRobin. After registering the database server on your localhost, use the Manage users... function in the context menu:
Here you get a list of users with options to delete or view/modify properties. If you click on the properties icon, you enter this dialogue where you simply enter the new password twice:
There is also IBConsole which comes packaged with the InterBase/Firebird SDK. It has similar functions.