Recently I had a client from Singapore try to log in to our web-app using a password that we gave him over the phone.
The password was short and alpha-numeric; no special characters. He couldn't log in after several tries, being very careful to input each character correctly.
We then decided to send him the password over email as a test.
He copy and pasted the password, and successfully logs in.
My theory on why this happened is because he was using a different encoding or international keyboard. Is there some way to prevent this from happening, or some things I can check for as far as encoding goes?
Tell him to send back the way he typed it, and compare it. if it's alpha-numeric, there's no reason it would be different.
(English characters are the same worldwide)
Related
We have been noticing a large number (~3400) of fake signups over the last year and have not been able to determine where they are coming from. Common parameters:
They often come from weird, yet validly formatted, email address (many in the .ru TLD or from thefmail.com)
Some use cyrillic or arabic characters in their name (we are basically focused only on US English speakers by our content)
They do NOT trigger the Intercom.io javascript for account signup notifications
They somehow defeat reCaptcha 3
They sometimes use URLs for their username
They don't confirm (devise_confirmable)
We've been handling these by disabling the accounts, and there's obviously a few items above we could use to identify these before they even get created, but I was wondering if someone's cracked this nut already or if there's some simple best practices (pwned db check?) that might cut this down to a dull roar or out entirely.
The two big "I don't get its" are bypassing the JS and defeating recaptcha. Is this just mechanical-turking?
Do you know whether these users have been created by the same IP address? (probably not). Are the accounts sporadically created or are they created in batches? The gem rack-attack could be used to mitigate this issue, especially if at least one of these conditions is satisfied. It also comes with some sort of fail2ban filter which could be helpful, as it is designed to detect suspicious requests from 'misbehaving' clients.
I also can't understand how they possibly bypassed recaptcha.
I want to make my applications password changing process a little more secure so that not just anybody can go on to an account and change their password, so my question is:
Is there a way to compare the password in a Parse database to what is entered in a text field? If the "Old Password" text field does not match the information in the database they will not be able to save their changes unless they get it correct. Is this possible? I know Parse encrypts passwords so I am not sure if this is possible and I have found no evidence in my search.
I don't believe this is possible to do. Even if you try to retrieve the user's password the result is an empty string. A workaround could be to try to log the user in again (in the background), which I think Parse allows you to do, and if the log in is successful..well then the password was right! Let me know if you can achieve what you want with this.
I have a blogging application. Once a blog-post is created by a user, it will be sent as an email to some of user's friends. I want a functionality where the friends will just reply to the email and the content of the email will go as comments for that particular blog-post.
One way to do this is to do something similar to what http://ohlife.com does. It basically creates a unique ID per user per day, has the reply-to attribute of the email set to post+{unique_id}#ohlife.com and probably parses this field to know which user is the email for, when it gets received. But it really has only 1 email address which is post#ohlife.com. The part after the "+" get's ignored by email servers. This also is applicable to gmail.
What I wanted to know, is whether this property is for particular email servers or is it universal? If it is not universal, is there is email server independent way of implementing this? I would not want this to be based on the email subject, as it's the trivial solution I know of.
it is depending on your mail server and how it is configured.. (although it is quite a standard) - for example in postfix:
recipient_delimiter = +
you could set it to anything you like .. i once configured it to be a dot so i can use it all over the web.. http://www.postfix.org/postconf.5.html#recipient_delimiter
but you could simply make it configurable in your application as well..
Besides using the email subject or address, one other easy way to accomplish this would be to just stick an identifier number at the bottom of the outgoing email's body. It would then come back to you in the quoted part of the response message. This is much less obtrusive than putting stuff in the subject or address, and if you're using HTML messages you can even make the code invisible.
I'm having some problems with Html.Encode and users wanting to use special characters. Firstly the characters are replaced by the html codes and so are not displayed properly. And then, if the text is later edited and re-submitted, an exception is thrown when these html codes are re-submitted.
Given that this is an intranet site and the possibility of a deliberate attack is almost non-existant, is there really any risk to not using Html.Encode? Is there any possiblity that someone would inadvertently submit some special characters which cause problems?
Or is there a better way around this problem?
Given that this is an intranet site
and the possibility of a deliberate
attack is almost non-existant, is
there really any risk to not using
Html.Encode
Yes, yes and yes again. There's always a risk by someone entering special characters in input fields. The golden rule of web development is never trust user input and always encode anything that might come from an user input.
Check everywhere you are calling Html.Encode as it sounds like you're double encoding your strings (possibly encoding on save and on display or encoding on a template/partial and encoding that again).
And yes always encode your strings even if it's internal, otherwise one disgruntled employee could cause some serious damage.
Firstly the characters are replaced by the html codes and so are not displayed properly
You are double encoding. You actually want to Html.Encode to display the HTML tags the user entered at all. Unless you actually want things like <ul><li> to be a bullet list instead of showing the tags.
And then, if the text is later edited and re-submitted, an exception is thrown when these html codes are re-submitted.
Whatever you did to allow the initial submission of those, will work to allow edit. Again, maybe because of the double encoding, you are getting into further issues.
Given that this is an intranet site and the possibility of a deliberate attack is almost non-existant, is there really any risk to not using Html.Encode?
Deep down You already know that way of seeing security is wrong ;)
What is the following portion of a Gmail URL for?
https://mail.google.com/mail/?**zx**=1efobg68r40co&**shva**=1#inbox
If you change it, nothing happens!!
I know Gmail is not an Open-Source program so we can't trace the code. But every website try to make the URL shorter so they ideally shouldn't add redundant data to the URL. At the same time they don't make any difference nor error if they change.
Edit: I know it's a parameter for a scripting language since I'm a PHP developer but as a developer I don't EVER add a useless parameter and I think it's obvious/primitive sense!
The acronym stands for "Should have valid authentication" as noted here:
http://googlesystem.blogspot.com/2010/07/gmails-shva-parameter.html
As others have noted, 1 is the default value.
If I'm remembering correctly, back when they were working on the current version of the interface, you could preview it by setting shva=2 instead of the default. That version is now the default and you can't get the old version, so shva does nothing now.
It may be used again in the future, who knows?
But every website try to make the URL shorter so they ideally shouldn't add redundant data to the URL...
This is self-evidently not true. Look at StackOverflow URLs for a perfect example. This post:
http://stackoverflow.com/questions/1692968/shva-in-gmails-url-what-is-this
could just as easily be (it works):
http://stackoverflow.com/questions/1692968
I don't think anyone worries these days about the extra couple bytes of data involved with an extra query string parameter.
Some of them saying it is" should have valid Authentication". We shall consider it OK.
But the real expansion of shva is "security host verification and authentication".
It always comes when you open Gmail.
We won't know what it 'exactly' means unless someone inside Google answers your question. But my guess would be that it has to do with security and encryption. Nothing happens when you change it because it is part of the cookie as well. So when you change it they must also compare it with what is set in the cookie.
"shva" is an acronym for "should have valid authentication". Apparently, the parameter is only included after a successful authentication.
The 1 is the default value applied to the parameter check. It's also a shorthand way for programmers to say true, like when you have successfully logged in.
The other part, #inbox, tells Gmail to load up your inbox as the first screen. You can change that to one of the other folders (or even labels you've created) to load them up.
E.g., https://mail.google.com/mail/?shva=1#sent will show your Sent folder items.
https://mail.google.com/mail/?shva=1#label/narwhals will load up your "narwhals" label.
Gmail, like many web services, serves a standard interface that will change to show only your information and data when you've logged in.
The particulars are referenced on their end through the use of an ID from the cookies or sessions generated after the login screen.