For example:
"I am a very secret person".
I'd like to show someone that this string includes 'secret' without revealing the rest of the string. Is there anyway?
Related
I am using the "sonata-project/google-authenticator" library. It allows me to generate a QR code as follows:
$g = new \Google\Authenticator\GoogleAuthenticator();
$salt = 'XJDDJKSLJNASDJNASDASDASD';
$secret = $uid.$salt;
$url = $g->getURL($uid, 'coinula.com', $secret);
My question is around this:
The secret I provide, is that the secret that these guys are showing to the user? So that secret is the "global" key and the qr code is just a picture version of this code?
Am I supposed to store the secret and keep it safe on my side? Or is that something that the user should be able to write down and decide if he wants to keep it. I.e. Is the purpose of the secret for me NOT to store it? Or is there a reason I must store it?
Turned out to be a dumb question, but I'll answer it anyway. The secret must be stored in order for you to match it to the user. Would've been nicer if you could specify your own secret. I suppose there might be a way, but I'm going ahead with this way. So I'll be using the secret that is generated and storing that in the DB in order to compare it.
How can I verify if an incoming field is a valid e-mail? Is there a way to use string-functions or anything in Firestore security rules?
Example:
Let's say I have a Create-Request with a field called "email". In my Firestore security rules, I would like to check if the email is a valid email address:
contains '#'
ends with either .xx or .xxx (a casual country-domain-ending)
has a '.' before the last three or two letters of the email
the '.' does not follow directly after the '#' - at least two letters have to be in-between
So that e.g. example#emailprovider.com gets accepted, but not example#.com.
I know that this check is quite extensive and further would like to know if it makes sense to introduce such a validation to security rules?
You can use rules.String.matches.
See
https://firebase.google.com/docs/reference/rules/rules.String#matches
https://github.com/google/re2/wiki/Syntax
How to validate an email address using a regular expression?
Performs a regular expression match on the whole string.
A regular expression using Google RE2 syntax.
If you want to set only email address then It's necessary to validate the field as email address.
I found an example of a regex (and adjusted a bit):
^[a-zA-Z0-9._%+-]+#[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,5}$
The source of this is at the bottom of the following page:
https://firebase.google.com/docs/reference/security/database/regex
You should also take into account the note as well:
Note: THIS WILL REJECT SOME VALID EMAILS. Validating email address
in regular expressions is difficult in general. See this site for
more depth on the subject.
I know that URI supports the following syntax:
http://[user]:[password]#[domain.tld]
When there is no password or if the password is empty, is there a colon?
In other words, should I accept this:
http://[user]:#[domain.tld]
Or this:
http://[user]#[domain.tld]
Or are they both valid?
The current URI standard (STD 66) is RFC 3986, and the relevant section is 3.2.1. User Information.
There it’s defined that the userinfo subcomponent (which gets followed by #) can contain any combination of
the character :,
percent-encoded characters, and
characters from the sets unreserved and sub-delims.
So this means that both of your examples are valid.
However, note that the format user:password is deprecated. Anyway, they give recommendations how applications should handle such URIs, i.e., everything after the first : character should not be displayed by applications, unless
the data after the colon is the empty string (indicating no password).
So according to this recommendation, the userinfo subcomponent user: indicates that there is the username "user" and no password.
This is more like convenience and both are valid. I would go with http://[user]#[domain.tld] (and prompt for a password.) because it's simple and not ambiguous. It does not give any chance for user to think if he has to add anything after :
I'm using the Authorization header with the Basic type for authentication.
I'm following the HTTP Basic authentication specifications which states that the credentials should follow this form -> userIdentifier:password encoded in base64
We are using an email as the user identifier and according to the email format specification, the colon(':') character is permitted.
The colon(':') is also a valid character in the password.
Knowing this, I'm looking for a creative way to parse the credentials part of the header that uses a colon(':') as the separator between userID and password.
In this case it's simple -> francis#gmail.com:myPassword
This is where it gets complicated -> francis#gmail.com:80:myPasswordWith:Inside
francis#gmail.com:80 is a valid email according to the email format specification even though this is not used very often. So where do I know where to split ?
We have made the decision not to accept an email containing a ':'. But we want to notify the user that his email is not valid, how can we ensure that we are splitting the string at the right place ?
Hope I asked my question in a clear manner, don't hesitate to ask for more details
Thank you
Don’t notify the user that the email is invalid. Split according to the RFC 2617 rules (everything after the first colon is the password), then try to authenticate, fail, and return a generic “authentication failure” message.
A situation where john#example.org:80 has password secret and john#example.org has password 80:secret at the same time, seems unrealistic.
If you require your users to register, you probably do it with some other mechanism (forms?) where you can easily separate the username and tell that it is invalid.
I have a very simple (rather stupid) question, I hope someone can clear my mind on this :)
I want to send an email to my site user once he clicks a button. This email will contain a link with the userID of a user in the link URL (as query param of a link).
Once the user clicks this email link, my server side code will parse and decrypt the userID query string key to get the user ID and perform some action on it.
I cannot use base64 encoding as it can be reversed and 'hackers' can get to know the real userID. I have to encrypt the ID but when I am using AES alogrithms for encryption, the encrypted text is not "understandable" by the browser, ie I cannot pass the encrypted userId text as a part of the URL because it contains un-encoded characters like "/" which the browser cannot by pass. One option I can think of is to base64 encode the encrypted text once I send it across via URL. Then I can bease64 decode and decyrpt it.
Is this approach better than using Uri.EscapeDataString() on the encyrpted text?
You should continue to base64 encode the AES data, as at that point it is likely binary rather than a string that can be escaped. You should also check that you are using url safe base64 encoding.
Use a one-way hash like SHA1 or MD5, and use JavaScript to send the values as encrypted. Then, if a hacker intercepts the request, they would only have the hashes and not the actual values. They could still send the hashes to login, though; one solution is to include a JavaScript parameter (generated via your server-side language) based on IP (but not possible for a hacker to find the formula for), and use it to salt the username and password hashes.
Then on server-side you would do (in PHP, in this case):
$ipHash = sha1("random" . $_SERVER['REMOTE_ADDR'] . "salt_here10381") // place this as a hidden element in the form and use it in the JavaScript to calculate the hash
$userHash = $_POST['userHash'];
$passwordHash = $_POST['passwordHash']
// TODO: Escape $ipHash, $userHash, $passwordHash
$results = mysqli->query("SELECT * FROM `users` WHERE SHA1(CONCAT('" . $ipHash . "', `user`)) ='$userHash' AND SHA1(CONCAT('" . $ipHash . "', `password`)) = " '$passwordHash'");
Then, if a hacker wanted to login with the hash and username they found, they would need the same IP of the user originally logging in whose credentials were intercepted.
Note that this assumes you have passwords stored in your database as plain-text, which you should never do.
For hashing with SHA1, on client-side, take a look at this.
To answer your specific question (I see I got a bit off topic, oops,) it would be acceptable to base64encode the hashes when you send them to the server. If possible, try to send it as POST data and save it in a cookie or session variable.
I think of a simple solution you try to generate a random number(make it as a key) and for the encryption use some simple technique of yourself like XOR 'ing the ASCII value of the characters in the user name with the key that you have generated .so the long random key results in a greater result.
When creating the email you need to encrypt the user ID, then base64 encode it, then URL encode it. Put this as the userID param in the link.
When decrypting the email you do the same in reverse; get the userID param, URL decode it, base64 decode it then decrypt it.
Remember to use a different intitialisation vector every time you encode a user ID. You will need to put the initialisation vector in the emailed link as a URL parameter too in order to decrypt it.