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.
Related
I am running Enea OSE 4.6.1 on a system that I have and every so often (sometimes a few days, usually several weeks), I am asked to change my password by the system.
I am wondering if there is a way to check the expiration date of my password, or modify said date. I do not enjoy having work to do and being surprised with the expired password. The end goal is to write a script to check the password expiration so I am aware beforehand.
I searched through some of the OSE Documentation I have on hand and did not see much about passwords (I do not have every PDF). I also checked through some of the source code and the validation process but see no mention of expiration, dates, or change. Finally, I was able to secure a list of all pre-configured command line commands and none of them mention (expiration) date for passwords. There is a command to change password but it mentions nothing of time or date.
I believe there is a way to create my own custom command line command I found in one of the OSE manuals, but in order to do that I will need to know where password expiration is stored.
Any information would be greatly appreciated as I know OSE is not too widespread. Thank you in advance.
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 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.
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?
i am making a business application and i cant afford other activation software to protect my software from being pirated. I am looking for some place to save my activation, trial and licence data in user's computer.
I think that if i use compact editions of sql server and give password to it, it will be impossible for any other hacker or cracker to modify activation data and pirate my software? Is this safe or i shoul go for anyother option?
First, you must realize that making it 'impossible' to crack has been tried and tried again by the largest corporations and most sophisticated products- and it has always failed.
Having said that, you can make progress towards encouraging your customers to purchase a license by using a password protected encrypted database, password alone is not enough.
Also, what do you plan on using for your password? Is it going to be hardcoded? Will you salt a hardcoded pwd with something unique to the system its running on? Will that be good enough, I'm assuming if thats all you do breaking it would be fairly trivial- disassemble your code and find the hardcoded password, and figure out how you compute the system unique value.
Please take a look at this other similar SO Question and its answers- some are quite good.