Given public key (RSA) encrypted with symmetric key (password) and if password is weak, then how is it possible to find password using given encrypted public key only.
Related
When performing actions that requires foreign key contraints to be disabled, one can temporarily disable foreign key constraints to perform such an action, eg:
Schema::disableForeignKeyConstraints();
// Do good stuff
Schema::enableForeignKeyConstraints();
This made me think if the restraints are disabled in the schema for all connections?
Is it possible for another connection in another process to break the restraint between the disabling and enabling?
I've tried to test this by running Schema::disableForeignKeyConstraints(); in Tinker, and opening a new terminal to attempt to break some foreign key constraints - but they still apply, and I'm not sure why.
The Schema builder uses
public function disableForeignKeyConstraints()
{
return $this->connection->statement(
$this->grammar->compileDisableForeignKeyConstraints()
);
}
and for MySQL, the compileDisableForeignKeyConstraints function is defined as
public function compileDisableForeignKeyConstraints()
{
return 'SET FOREIGN_KEY_CHECKS=0;';
}
so it seems that running Schema::disableForeignKeyConstraints(); should simply disable the foreign key restraints for the entire schema - yet it seems to only work on a per-connection basis.
Is this a Laravel thing or a MySQL thing? How does it work?
I have a webapplication that will write to a database using HTTP POST. The database is allready populated with data and have PK set to ID. When I do the HTTP POST to Web API that again writes to database. What is best practise when it comes to assigning the correct and unique primary key along with it's data?
The best pratice for do that is set primary key as INT AUTOINCREMENT and when you run the INSERT query does not specify the primary key and this is automatically set, this ensures you to be unique.
I have a Mysql database that stores login data. The passwords and salts are saved as sha512 hashes. Now, should the value in the password column be changed, I would like to implement a condition that the salt MUST be changed, or the mysql command is invalid.
CREATE TABLE loginData(
id int UNSIGNED SERIAL DEFAULT VALUE,
email varchar(64) NOT NULL,
password binary(64) NOT NULL,
salt binary(64) NOT NULL,
PRIMARY KEY(id))
ENGINE=InnoDB;
Now, I was thinking of something like the integrity constraints of foreign keys, but obviously I should not connect the password and salt column as foreign keys. Is there any way to prevent updating only the password column - so a new salt HAS to be given - on the Mysql side? Preventing it only on the side of the accessing code feels incomplete.
One way you can possibly do it is to not actually update your login records for password changes, but to insert new records. You would need a schema change to add a tinyint fieldname named active or similar to store a flag indicating which is active login.
You could then add unique indexes on email/salt and email/password in order to force uniqueness on those combinations, meaning you could never have the same email with the same salt entered and also you could never enter the same email/password combination. Any inserts with same email/salt or email/password would fail. If you don;t need password uniqueness (you can obviously just not add the email/password unique index).
When you lookup the login to actually perform the credential check you would just have to add WHERE active = 1 to your query filter.
You would probably also want to wrap the operation of inserting the new salt & password record and updating the old row to active = 0 within a transaction so that either the entire transaction succeeds or fails, thus preventing cases where users get stuck without a login.
Unless you have multiple systems accessing the database, I wouldn't say preventing it only on the accessing code is incomplete. You can prevent admins from manually updating the data by not giving them the appropriate write rights on the table.
But if you must enforce this in MySQL, you could consider adding a trigger (code which is run when after updating a record), but in case the salt comes from your application, this is probably not feasible. Then the best option is to only provide access to the table through a stored procedure (code residing in the database), which enforces the integrity of the table.
See http://dev.mysql.com/doc/refman/5.6/en/stored-programs-views.html
I have a table TblUserLogin with columns LoginID int, Password varchar(50), LoginUserName varchar(150), Designation varchar(100).
My requirement is that whenever we are using select statement to this table we are able to see the password which is entered (which is sensitive information).
Is there any way so that we can encrypt the password column so that when ever we use select statement that information will be seen in an encrypted way and will not affect the code which is accessing the password column or inserting new password?
In simple words when "The password column shown as encrypted when it is accessed from Management Studio using select statement, but when accessed programatically it returns the actual non-encrypted password".
Try this:
CREATE Procedure [dbo].[EncryptPasswd]
#user_id int,
#username varchar(255),
#passwd varchar(255)
As
Begin
Declare #res varbinary(2000)
IF NOT EXISTS(select * from sys.symmetric_keys where name='##MS_DatabaseMasterKey##')
CREATE MASTER KEY ENCRYPTION
BY PASSWORD = 'xyz#123'
IF NOT EXISTS(select * from sys.certificates where name='EncryptTestCert')
CREATE CERTIFICATE EncryptTestCert
WITH SUBJECT = 'xyz#123'
IF NOT EXISTS(select * from sys.symmetric_keys where name='TestTableKey')
CREATE SYMMETRIC KEY TestTableKey
WITH ALGORITHM = TRIPLE_DES ENCRYPTION
BY CERTIFICATE EncryptTestCert
OPEN SYMMETRIC KEY TestTableKey DECRYPTION
BY CERTIFICATE EncryptTestCert
INSERT INTO Users(user_id,username,passwd)
SELECT #user_id,#username,ENCRYPTBYKEY(KEY_GUID('TestTableKey'),#passwd)
END
Use this sproc whenver you insert a new user into your user table.So this will encrypt the password and insert.
In general, unless you absolutely can't avoid it, you should not store passwords in a database either in the clear or using reversible encryption.
Instead you should store a hash of the password, then when you need to compare it, hash the user input and compare the hashes.
you could encrypt the password in sql server 2008
read this article, describes very clearly
I have a permissions issue with regard to using a symmetric key under a specific user name when a stored procedure is executed.
Despite running
GRANT CONTROL ON CERTIFICATE::myCert TO myUser
GRANT VIEW DEFINITION ON SYMMETRIC KEY::myKey TO myUser
I still get the same error:
Cannot find the symmetric key 'myKey',
because it does not exist or you do
not have permission.
The Master Key, Certificate and Symmetric Key were set under the database the user name relates to.
If I run the SP under Windows Authentication it works fine.
Here's the stored procedure:
OPEN SYMMETRIC KEY myKey DECRYPTION
BY CERTIFICATE myCert
INSERT INTO sp_Password
(billEncryptPassword)
VALUES(ENCRYPTBYKEY(KEY_GUID('myKey'),#billEncryptPassword))
RETURN ##IDENTITY
CLOSE SYMMETRIC KEY myKey
What have I missed?
I am having the same problem even while running this as a SysAdmin.
To work around it I am currently closing all open keys which works fine. I'd much rather close only what I had open though.
CLOSE ALL SYMMETRIC KEYS;
--- Addendum
I just tried this with AES_256 vs DES encryption and the AES_256 worked on my end.
You're missing CLOSE MASTER KEY afterwards and that's messing with your subsequent encryptions/decryptions.