I am using Asterisk 14 with pjsip. I would like to disable authentication requirements for certain users, so when that user registers I don't have to send the "REGISTER" request twice (the second containing credentials). I am not sure where to do this using pjsip.
Thank you
On first register server send back nonce, which used for encrypt password on second attempt.
So no, it is not possible do secure registration without that.
But yes, you can patch any channel driver and do whatever you want with it. Sure you also have patch clients acordinly.
Related
I want to retrieve data from an applications back-end. I have to send the user's email via an API request from the front-end website in order to do this.
Is it good practice to send the user email in a GET request or a POST request? More specifically, is it good practice to not include a users email as a URL parameter because you don't want some other third party to see it?
Thanks
You'll absolutely want to make use of POST requests rather than GET requests for querying email addresses, as GET requests should never be used for sending sensitive information.
Bearing that in mind, you also have to take into consideration what you're doing with your endpoint to begin with. If you're simply requesting public information about an email address (such as resolving the server name or IP), then perhaps a GET request would suffice.
Keep in mind you cannot pass any authorisation headers with a GET request, so if you're querying something like whether the email address in question has a registered account on your website, anyone would be able to find out your user's email addresses by spamming requests until they got a 200 response (thus validating a registered email). And knowing a valid user's email address could serve as an attack vector at a later stage.
In short, you most likely want POST. Only use GET if you're purely querying information about the domain that the email is hosted on.
Well, POST-request is better for hiding GET-params from logs.
The best you could do - is encrypt data being transferred. You can use POST-request with SSL-encryption and it will be good enough for regular systems.
I'm new using Webflow and I don't know how to do that: I want to implement a recovery password flow, I'm taking the user's email, generate a random ticket and store it with hibernate. The problem is that I don't know how send an email to the user with a link to another flow which should check if the ticket is valid and then let the user change his password. Before using webflow I was sending the next URL: (http://localhost:8080/changePassword?ticket=15teumv5huebt...) changePassword is a view in my project but I know this URL will be overriden. Can anyone give me some suggestion? Thanks in advance.
well, if your flow's id is "changePassword", you should be able to send a link with "http://localhost:8080/changePassword?ticket=15teumv5huebt..."
you might want to automatically replace localhost by the server ip and do the same for the port number
also you might have to use your application's name "http://localhost:8080/appName/changePassword?ticket=15teumv5huebt..."
When a customer signs up for a site, we want to let them know whether a username/email is available for use.
We have a httphandler that serves the purpose of feeding a jquery script that showsthe customer whether or not their desired username/email is available.
The question is:
The service can clearly be seen being called when you view the request in fiddler.
It shows /emlhandler.asmx?name=xxxxxxxxxxx#yyy.com
From the handler, a simple 0 or 1 is returned to indicate whether or not the name/address is available.
My concern is that this seems like a major security issue that would be very easy for an inexperienced person to exploit to discover all the users on the site.
So friends, how do you protect your site info and still allow the ajax callback to provide a great user experience?
Thanks.
Heath
You are being slightly paranoid here. Every site that allows user registration has to do something similar. One thing you can reasonably do is add a slight delay (maybe 2 or 3 seconds) to the handler's processing in order to reduce the likelihood or ease of a brute-force attack. Frankly, I don't think anyone would bother.
Another option is just to ignore repeated emails and send a verification email before a user's registration actually becomes active. If a new user attempts to use an existing email, the original email owner receives the verification and can cancel or ignore it. But I don't recommend this.
I'd say the vast majority of the sites I've used will just immediately say "this email address is already registered... did you forget your password?" Just knowing an email address is already in use on a given site does not in itself represent a security breach.
One possible solution would be to only enable POST requests for that method.
And since you cannot invoke services from JavaScript from another domain (XSS - Cross-site Scripting) without your authorization, then you would be protected.
However this technique would prevent malicious users from calling your web service to discover user names but this wouldn't prevent the user to automate a process to simulate user entering data in a text box to force a call to the service, in that case, perhaps you could allow just a number of requests per user in an X amount of time.
You could keep track of the number of attempts using the Session object from your web service
Another approac would be to add a re Captcha to your site, however this would decrease the level of responsiveness if you used to allow your users to capture a user name and as soon as they write you call your service. Implementing would require your users to write the auto-generated captcha in order to submit your data
I have my little web application, with simple registration strategy - provide email and password and you are done.
Recently bot's starting to attack my application, registering big number of users from non existent emails using the same passwords.
I want to prevent that. My idea is to extend login verification, but check the existance of email address. Do you know any web services (prefereably WCF) that could do that?
This is definitely not the way to solve this problem. Try one of these
Allow user to enter only username and send auto-generated password to their email.
Send a verification link to the user email and approve him/her only after verification
This has been discussed on How to check if an email address exists without sending an email? . Basically there are ways verify email addresses, but in practice none of them is reliable. However, you can still check via SMTP, and if the server denies the existence of the expected user, send him an email with a verification link anyway. This does not prevent spammers from setting up fake servers that acknowledge the existence of any user, of using other peoples email addresses, but it's probably the closest you can get to your initial requirement of having no verification email.
I would recommend you to update your registration form. Try to use something tricky for bots. For example, post the form via AJAX with JSON object wrapper.
Try a service like: http://elasticemail.com/
You can use the api to check if the email was delivered. There is also a 'bouce list' you can check.
I'm starting to size up a project where I feel security needs strike a little closer to home. What tools and techniques could I look at to attempt to raise an alarm when a valid login is used, but the owner of the login has given it away or had it stolen. I would prefer ASP.NET, then MVC 3, oriented stuff.
This is not a silver bullet, but perhaps you should consider employing some kind of two-factor authentication. For example: when a user creates an account with you, you require that she provide you with a phone number where she can receive text messages as part of the registration process. Then, when she attempts to log in, you text her a temporary authentication code to be used in combination with her username and password.
This ads an extra layer of security to the system, because an attacker would have to both know her username and password and have physical access to her cell phone in order to compromise her account.
I hope that's helpful.
Seems like you would get a lot of false positives... but you might try checking what IP address the login is coming from. Most people will log in from the same IP address most of the time, so when that changes, it's at least a warning sign. If you want to be very strict about security, you could maintain a whitelist (for each account) and require that they get their IP address added to the whitelist before logging in.
My bank (Chase) does this by checking a secure cookie during my username/password login. If the cookie is missing or corrupted, they require a second form of authentication, which is either a code sent via text to my phone number on file or via email to my email address on file. Once the second form of authentication is complete, they set the secure cookie and then I can login from that browser with only username and password.
Implement your own Membership provider and add field locked to model,
check for user being locked on login and do some actions
It might be useful to think of the factors of the Authentication process, so that you can be sure that you are sufficiently covering things. You can easily get ridiculous with the layers of assurances, but I happen to find that most banks now have a variation on a simple model. All of this is, of course, over SSL
User submits account name. Additionally, you can require a secondary piece of information, last 4 of account number or year part of date of birth.
Optional, but a good idea: present the user with a counter sign, that is something that verifies the identity of the server. The user selects this at registration and should be looking for this every time they attempt to log in. This aids in preventing phishing.
System checks to see if the current system using IP lookup or cookie is associated with the account. If not, presents challenge question along with password input. Otherwise, presents just the password input.
Complicated, but can actually be done in 2 pages and more secure than is usually required.
I've presented this workflow to a few bank clients and they usually remove one or two of the checks for a balance of user friendliness.
With phones with text capabilities being so common, the idea of SMS verification code as mentioned by others is also a good idea, though I haven't implemented this in a system yet, personally.