What are the allowed characters for the passphrase? Are all unicode valid?
(SQLite documentation search gives back no results for "password")
For length I read here that it is considering only the first 16 characters of the password.
Related
I want to create/update realmdb password on path __password.
I cannot find clear documentation about it, i just explore realm studio and realmdb graphql API.
From realm studio i found salt, digest (sha512), and hash.
From that key i produce sha512 hash with https://www.convertstring.com/Hash/SHA512.
the problem is, character length from sha512 just 128 character. i tried to compare with other hash password, they have 684 character.
the other key i found inside path __password such as iterations and keyLength, i don't know what that for.
actually i can use this API for create user.
Realm.Sync.User.login([**serverURL**],Realm.Sync.Credentials.usernamePassword([**username**], [**password**], true));
but i want to update password too. there is no documentation about changing password.
the question is :
How i can produce sha512 with output 684 character ?
How to update realm password directly to path __password ?
What is best practice to update user password ?
Db2 allows to set a password in the connection using
SET ENCRYPTION PASSWORD 'mysecretpw'
This avoids having to set the password on each ENCRYPT() / DECRYPT() usage.
However, how can I remove the password after I finished my work so that other parts of code that work with the same connection are not able to use my password ?
I didn't find a 'REMOVE/DROP ENCRYPTION PASSWORD'.
Setting the password to an empty string SET ENCRYPTION PASSWORD ''caused problems when my code was invoked multiple times in the same process: the second invocation got 'NO PASSWORD SET' SQL20143N / SQLSTATE 51039 even though it did set the correct password again using "SET ENCRYPTION PASSWORD 'mysecretpw'" again before using ENCRYPT/DECRYPT ... Db2 also says that you have to specify a password between 6 and 127 bytes ...
Setting an arbitrary string as new password (e.g. blanks) is also not ideal, as this does not allow Db2 to detect 'no password set' conditions so that you don't realize that you are encrypting / decrypting with a wrong password ...
So how to clear the password correctly ?
The Db2 LUW documentation (at version 11.1) for SET ENCRYPTION PASSWORD does not state it explicitly but the product allows you to set the password to an empty string with the result that subsequent encrypt/decrypt actions in that connection will return -20143 sqlcode. When I test this behaviour with the CLP it behaves as expected on Db2 LUW.
So while both Db2 for Z/OS and Db2 for i-series for SET ENCRYPTION PASSWORD explicitly mention the empty string behaviour for the password (and the Db2 LUW knowledge center does not), it appears all three code bases have the same behaviour as regards the consequence of setting the password to the empty string.
If you have a testcase that proves you get an -20143 sqlcode even after using SET ENCRYPTION PASSWORD to a valid good password, then perhaps you should publish that testcase or open a PMR with IBM. If your code is multi threaded , you may get unexpected results as the password is in special register and changing it is not under transaction control, so there may be timing issues.
Removing the password seems to be possible either via disconnecting the session or setting it to an empty string in a single-connection scenario, and with the CLP the product appears to behave as expected for me when I set the password to an empty string, and subsequently set it to a valid password for the same connection.
I found that Meteor default use sha-256 to hash password. but I am confused that same password for each account after hashing become different string stored in the database. Anyone would tell the detail implementation, thx
Per the Meteor docs, accounts-password uses bcrypt.
If you look at the source code of loginWithPassword, you should be able to find out where the salt is stored. As a second source, read MasterAM's answer to Laravel & Meteor password hashing which indicates that Meteor from 2011 on uses $2y$ hash strings, i.e. PHP CRYPT_BLOWFISH, which uses
CRYPT_BLOWFISH - Blowfish hashing with a salt as follows: "$2a$", "$2x$" or "$2y$", a two digit cost parameter, "$", and 22 characters from the alphabet "./0-9A-Za-z". Using characters outside of this range in the salt will cause crypt() to return a zero-length string. The two digit cost parameter is the base-2 logarithm of the iteration count for the underlying Blowfish-based hashing algorithmeter and must be in range 04-31, values outside this range will cause crypt() to fail. Versions of PHP before 5.3.7 only support "$2a$" as the salt prefix: PHP 5.3.7 introduced the new prefixes to fix a security weakness in the Blowfish implementation. Please refer to ยป this document for full details of the security fix, but to summarise, developers targeting only PHP 5.3.7 and later should use "$2y$" in preference to "$2a$".
Thus, look for the $2y$ string in the database, and extract the salt from it.
I'm developing an app that requires the storage of Portuguese characters. I was wondering if I need to do any configuration to prepare my SQLite db to store those considered special characters. When I query a db table that contains those characters I get a '?' (without quotes) in their place.
Probably an encoding problem. Is your DB/client using UTF-8?
you should check your DB encoding with PRAGMA encoding;, be sure your client does it's job using the same encoding and verify that the encoding used handles well those Portuguese chars.
On a modern Unix or Linux system, how can you tell which code set the /etc/passwd file stores user names in? Are user names allowed to contain accented characters (from the range 0x80..0xFF in, say, ISO 8859-1 or 8859-15)? Can the /etc/passwd file contain UTF-8? Can you tell that it contains UTF-8? What about the plain text of passwords before they are encrypted or hashed?
Clearly, if the usernames and other data is limited to the 0x00..0x7F range (and excludes 0x00 anyway), then there is no difference between UTF-8, 8859-1 or 8859-15; the characters present are all encoded the same.
Also, I'm using /etc/passwd as an abbreviation for something along the lines of "the user identification and authentication database (sometimes termed a directory service) on a Unix-based machine, usually accessed via PAM and sometimes hosted on other machines altogether from the local one, but sometimes still actually a file on the local hard disk, conventionally called /etc/passwd, often supported by /etc/shadow". I'm also assuming that the equivalent questions about the group database (often the /etc/group file) have the same answer.
It's all ASCII. But the password itself is never stored - only the results of the one-way hash. If you're wondering what characters can be in the password itself, it depends on the locale, which will restrict the characters your terminal is able to deal with. See "man locale"
From the BSD man page:
"/etc/passwd ASCII password file..."
As for usernames, I can tell you that Solaris only supports ASCII. I can't speak for other Unix-en.
"Not every object in Solaris 2 and Solaris 7can have names composed of arbitrary characters. The names of the following objects must be composed of ASCII characters:
* User names, group name, and passwords
* System name ...
"