I'm using Devise for authentication, and I need a way to quickly change every user's password to be the same password so that I can test locally using production data. Because there are a bazillion callbacks in this legacy codebase, and innumerable surprises lurking, and because it takes a really long time for the Rails environment to load, I would like to be able to do this in one SQL query.
So, I created a user, set the user's password to "Passw0rd" in the UI, then grabbed that encrypted_password field and copied it to all the other users, but Devise busted me for having an invalid hash. I assume this means that the encrypted password is salted somehow using other pieces of the user entry, which is pretty smart, but it makes it hard to imagine how I'll accomplish this in SQL.
Does anyone know how the encrypted_password field is structured so that I could roll my own in the database?
Related
I'm working on a project where multiple users work on for example Documents. Every user can own one or more document, edit them and release them again. A Central database handle what user own what documents.
Initial i started with SQLAlchemy and i thought the following workflow:
An user table
A Role table with corresponding allowed actions
Couple the users and the roles
Every user start an engine on the server.
But then i saw the following sentence in the tutorial(SQLAlchemy 1.4 tutorial - Enginehttps://docs.sqlalchemy.org/en/14/tutorial/engine.html)
The engine is typically a global object created just once for a particular database server, and is configured using a URL string which will describe how it should connect to the database host or backend.
Since then i start running in circles when it goes about login / logout and multiple user that have access to the database.
My first question is: What are normal workflows for this kind of situations?
Have a single 'Admin' login that handle all the actions and handle the user login as separate python functionality
start as what i thought that is logical but move the engine to the user (not sure if this is possible since it looks like just move the same problem to another place)
A Webserver? (Most examples i see use one... but except for logging in i don't need it currently)
Something else. because i don't know it
My Second question: Please link to some source that can me help bring up my knowledge
I have no software background so forgive me if my question is almost basic knowledge...
The title actually says it all, but I'll write my thoughts as a piece of context here.
From what I understand, the de facto method of storing passwords at the moment of writing is by salting and the hashing (correct me if I'm wrong), the point of this being that the passwords are not stored in plaintext anywhere, and the salt prevents rainbow-table attacks and such. I'm not super proficient on this, but this information I've gathered from the web.
Okay so, it's again time to change a password. If I choose the same password, the salted hash will match and I will get a prompt that says the password is the same as previously. Now some systems also prevent you from setting your password to e.g. 50% or 70% similar to your previous password, or one of your previous passwords.
I believe this to be fine security-wise, but how is this done if the passwords are not stored in plaintext anywhere? Or are they?
The answer may be simpler than you think, often you have to enter the old password together with the new one to change it, so the application gets the old password from the user. This is actually a good thing security-wise, because only a user knowing the old password can change it to another one.
As #martinstoeckli says, the simplest answer is that you usually have to enter your previous password when you change your password - so it can just compare the two in memory.
However, it's also possible to check for similar passwords even if the old one is stored hashed, by taking the new password, applying various transformations to it (changing individual characters, reducing the number on the end by one, removing the last character, etc), hashing those permutations, and then comparing those to the previously stored password. If you're using a good password hashing algorithm (bcrypt/scrypt/Argon2id/PBKDF2) then this will be fairly slow, but with faster algorithms then it wouldn't be a noticeable delay.
It's worth noting that these kinds of transformations are commonly used by attackers if they had access to previous passwords, and are also used with wordlists to try and guess variants of common words.
Supposing there were 3 or 4 developers using Mercurial, and all making updates to a project. Right now, usernames are self-configured.
If I pull changes from a colleague, (which may include other changes he pulled from a different colleague), how can I be sure the usernames on each commit actually were authored by that user, and not a different user who might have entered a fake username on that commit?
I assume Mercurial has some solution for this problem built in, perhaps using cryptography to compare the username to the hash and private salt or key or something.
Is there a way to validate authors for each commit? How does this work, and is it possible to do this whilst maintaining the Distributed nature of our Version Control System, or will we need an authenticating server?
You use the GPG extension.
That means you are using an OpenPGP system, and all that entails.
There is a discussion, about the past, present and future of signing.
I'm using Play 2.1.x and I'm wondering if there is a way to encrypt passwords that might be needed for database access? I have a configuration entry that stores the database server url, user credentials for accessing the database and I do not want to leave my password as plain text. How can I have my user credentials encrypted? I want to later un-encrypt when I use them within the context of my Play server. Any pointers?
The problem is where would you store the decryption key. If you store it in the same (or similar) configuration file, the entire exercise is moot.
I am guessing that you do not want to put the plain text password in application.conf to avoid having it show up in version control system. One way of mitigating that kind of leak is to have a different store for sensitive configuration files for production systems (a different repository that has fewer accessors works nicely).
I have a project running in vb.net. It's currently a very small project, so I have used XML serialization as the main way of storing information. I.e. creating a xml file in the .exe folder. and saving/reading from there.
Problem: Since the project is small, I have no SQL database setup and I would like to keep it that way. But I do want to create a user/password for access to the program.
What I have tried: I have tried using XML serialization, but hiding the xml file. Once I hide it, I'm unable to access the file (saying I have no permissions).
What's a good way to have the same utility without using SQL and not giving away security?
Hiding the file is pointless. You should simply hash the passwords and then store the data just as you do for any other data. That's exactly what you'd do if you were using a database too. When a user registers, you hash the password they provide and store the result. Anyone can then view the data without breaching security because they cannot get the original value from the hash. When a user logs in, you hash the password they provide and compare that to the value in the database and, if they match, the user is authenticated.
You should do some reading on hashing in general and also consider adding a salt for extra security, although that may not be worthwhile in this case.