NEED HELP!!!! :(
I have to finish a task in our project, lets say for example employees table has columns employee_id, username and password...
How will i print the username and password based on employee_id? please help me :(
This is one of the best ways to accidentally passwords and embarrass your company.
Never store passwords in plain text!
and certainly never print them out.
You should destroy your password column and replace it with an SHA-512 hash.
To answer the question:
SELECT Username FROM employee WHERE emplyee_id = #id
What are you using? T-SQL?
First of all NEVER store/print passwords in plain text. But..
SELECT username, password FROM table ORDER BY employee_id
Or if you want to select the username for each employee individually then
SELECT username, password FROM table WHERE employee_id = #id
Where #id is the employee id number of the employee you want the information about.
Related
I am using the pgcrypto extension in Postgresql to encrypt and salt the storage of user passwords in a database and I am having trouble retrieving them.
Specifically, the insert statement for a user looks like this:
INSERT INTO Users (username, password) VALUES ('test1', crypt('Password1234', gen_salt('bf', 8)));
This works fine however when I try to retrieve from the database, this query:
SELECT username, password FROM Users WHERE username = 'test1' AND password = crypt('Password1234', gen_salt('bf', 8));
returns no results, the query does not fail, just no results.
Currently, I am not using python to interact with the database (I will be in the future) I am just using psql in the terminal. I know something is wrong with this query but I am not sure what and how to fix it. Is there some other way that this should be structured or what am I doing wrong? Thanks for any help!
You are re-salting the password with a new salt, which of course leads to a different answer than before. That is the whole point of salting.
You need to reuse the first salt in the new hashing, which you do by feeding the password hash in place of gen_salt(...). (The stored hashed password has the salt embedded within it, and crypt knows how to extract and reuse it).
SELECT username, password FROM Users WHERE username = 'test1' AND password = crypt('Password1234', password);
But, why are you selecting "password"? Once you have verified that is hashes correctly, what further use is there in seeing it?
Talking to some coworkers they said that we do not should check if the unique key already exists with a SELECT. The check must be done with constraints error returned by the database.
I have the following scenario:
I need to return a message to the user informing if username OR
email is already registered(username and email is unique key).
I need to generate the password hash to insert a new user.
If I validate username and email(both are unique keys) based on the error of constraint violation returned by the database I can not know if it is the username OR the email that already exist registered.
If I simply INSERT the user into the database before checking the existence of the username and email, and one or the other already exist, I would be wasting unnecessary processing time for having generated the password hash.
What would be the best approach in this case? Considering data integrity if using a SELECT before INSERT.
You could proceed like this:
INSERT INTO users (username, email, password)
VALUES ('newuser', 'newemail', NULL)
ON CONFLICT (username) DO NOTHING
RETURNING id;
If you got an empty result, there was a collision with an existing user name.
If you get a constraint violation, there was a collision with an existing e-mail address.
If you get an id, back, set the password:
UPDATE users
SET password = 'newpassword'
WHERE id = v_id;
If the table has a fillfactor of less than 100, and there is no index on password (which there shouldn't be), this could be an efficient HOT update.
But I would measure if hash creation is more expensive than an extra database round trip...
Assuming I have a (over simplified, non secure) table that looks like:
CREATE TABLE users (id SERIAL PRIMARY KEY, user VARCHAR(25), _password VARCHAR(25), email VARCHAR(80));
I want to add a additional failsafe on the column _password that prevents it from being returned on a SELECT * FROM users call, is this possible in PostgreSQL and if so, how?
I tried some versions of https://stackoverflow.com/a/7250991/929999, but this probably isn't what I was looking for. But that got me thinking that there might be a constraint that could be created. I can't find anyone who's tried this or asked it before, so I'm kind of lost seeing as I'm not a database expert by any means.
So for now I dump all results from the database into a custom dictionary placeholder in Python with a function called .safe_dump() that removes any keys starting with _<key>.
And I guess I could create a separate table containing a list of sensitive keys and match those on every SELECT statement via a JOIN or similar, but that would just move the risk of accidentally retrieving a sensitive key from the SELECT call to keeping that "JOIN table" updated.
Is there a flag in PostgreSQL that can filter out of block calls trying to access a key while still allowing it to be used on WHERE x=y clauses?
You can deny permission for that column:
CREATE TABLE users (
id SERIAL PRIMARY KEY,
"user" VARCHAR(25),
_password VARCHAR(25),
email VARCHAR(80)
);
REVOKE ALL ON users FROM laurenz;
GRANT SELECT (id, "user", email) ON users TO public;
test=> SELECT * FROM users;
ERROR: permission denied for relation users
test=> SELECT id, "user", email FROM users;
id | user | email
----+------+-------
(0 rows)
If you'd rather want exclude the column from the output, use a view:
CREATE VIEW users_v AS SELECT id, "user", email FROM users;
GRANT SELECT ON users_v TO PUBLIC;
I'm struggling with this particular issue, I have the following tables, please see the columns and their properties:
User
id [pk]
status
user
password
contact [fk]
created_log [fk]
Creation_Log
id [pk]
user [fk]
created_on
Please notice the User.user and the Creation_Log.user, to make an insert into User, the check validation for the FK of creation_log is restricting me from doing it, and the same if I go to Creation_Log and try to generate a new one, it'll ask me for the User.
Is there anyway I can turn the checks off to create at least one admin user?
Simple question, however google can't help in reasonable time.
Ok, I have user table in my_db database with id column.
I want to run very simple query
SELECT id FROM user;
but it fails.
ERROR: column "id" does not exist LINE 1: SELECT id FROM user;
Can you imagine?
Ok, Running
SELECT * FROM user;
outputs the list of internal postgresql database users, which is nothing to do with my users, it's data from completely another [internal] database.
However, connection with my_db was established.
user is an internal function (and a reserved word) returning the currently logged in user.
To use that as your own identifier, you need to quote it:
select id
from "user"
or
select id
from public."user".
But you should really avoid reserved words as table names (or any name that requires quoting the identifier)
The following query can be rewritten as
SELECT id FROM my_db.public.user;
Where id is column, my_db is database, user is table name, public - is the schema. More about schemas:
http://www.postgresql.org/docs/9.1/static/ddl-schemas.html
So you don't have to rename the table name.