I am working on a project involving GPRS. In particular I use u-blox Lisa-U200 GPRS/GSM chip. Ran into a problem with the PDP contexts when I started testing it out with different carriers. And after spending days on Google I don't seem to find the answer anywhere.
Why do some phones/devices require APN Authentication (PAP/CHAP/None) and some don't? Or as I have titled the question - how do mobile devices (smartphones) detect APN Authentication method automatically? Or do they at all?
The way I test it is this - Linux box, running pppd with a chat script. The chat script defines the context (AT+CGDCONT=1,"IP", and so on) and starts the connection.
The symptoms - if I don't specify the authentication method in the PDP context explicitly it does not even activate (or LCP negotiation fails in the ppp). From the little I understand about GPRS networks this makes sense - I suppose because the gateway node refuses the context if it does not indicate there will be authentication to follow.
Tested with few operators and here comes the most weird part - some of the operators I tested work ONLY if I set it to either PAP or CHAP (and provide correct username and password). And some work whatever I specify (NOAUTH, wrong user/password, etc).
The ideas I have come up with so far are:
1) Provide option to the user to select authentication type. (Not the approach I am fond of because I prefer the user to enter as little as possible.)
2) If the user has set a username/password for the APN - set the auth method to CHAP (I have noticed most operators support both CHAP and PAP). If not - use None as method. (Sounds reasonable?)
3) Brute force - set to CHAP, activate - watch for error; if failed - set to PAP and activate, etc... (Can't say I am too happy about it)
Please excuse me if I answer a very dumb and common question with a well known answer in the mobile industry or if I am completely off track in my logic here, but I am a software developer and that just doesn't make any sense to me :)
Thanks to anyone who shares some experience and knowledge on the topic!
Related
I have an application with (nuxt js using nuxt-auth) with local authentication so far (later I want to add git and google auth).
Now I need to add authentication to invoke other services / API (like google cloud rest API, payment system, youtube API, etc...)
The question is: the user is authenticated only once (during login to the application.) but each of these 3rd party APIs has its own authentication.
How to implement multiple authentications. (I read the documentation and google for the entire day but there is no clear answer).
As of today, it looks like it is not doable (people are needed on this module): https://github.com/nuxt-community/auth-module/issues/889
So, you would need to make it manually by plugging the APIs yourself.
Answer to your latest question~comment
Nuxt is indeed nice with some of it's modules (but you can totally dislike it, no problem :D).
First thing that you need to know, is that this project (nuxt-auth) is not the biggest one, #pooya is doing his best but he is on a lot of projects, so he cannot give all of his love to it. Then, you also need to understand that it's working great but it's still in a decent beta state with a lot of missing features, needed documentation and a lot of small things to make it an all rounded solid top notch solution.
That do not mean that you should not use it, I'm just saying that this module do have some limitations. Hence, the fact that it is not supporting a whole lot of OAuth solutions in a clear + simple + flexible way. And some breaking changes may be introduced in future updates.
The module is aimed towards having an OAuth solution to block the content of your website behind it (in my opinion). It means that you will usually use a single login solution and then, being able to have access to your app. I don't think that it's a viable multi-OAuth solution (yet).
Some services don't even need to use a solution like this. Stripe for example, should not be handled on the frontend but communicate with a backend for sensitive variables and just send minimal info thanks to Stripe Elements.
That said, the most common solution is JWT or OAuth2, and you could totally have a backend service or service like Okta, Auth0 or alike, do the heavy lifting by allowing simple logins to providers (Github, Google etc...).
To sum up, you do connect to this backend/service thanks to nuxt-auth, the service itself does the provider connection and you get the best of both worlds while still connected in a secure way through your initial nuxt-auth entry point login.
Or you could try to reach the community on Discord, see if somebody knows how to do it. Or even try to read the source code to see if it is currently feasable.
And that's my 2cts.
Every application that generates dynamic content must have a server whose address is embedded inside the application to enable communication with server.
Now in the case of WhatsApp definitely they have also embed the server's address inside the WhatsApp application. For example someone reverse engineer the WhatsApp apk and found the address of the server, as well as he also found the parameters and all the stuff that the application sends to the server (i-e session, token, authentication key etc etc) for successful communication, so is that mean he can use these same parameters structure and the server address in different third party app to play/communicate with the WhatsApp server? Because server is just an electronic device that works on the digital signals and thats it. Server don't know that these parameters are coming from the authorized WhatsApp apk or from third party apk.
If yes, then don't you guys think that there should be solution to that problem?
If no, then what are the techniques and algorithms they are using to stop requests from unauthorized/fake apps.
I believe not any employee from WhatsApp will answer here to share the algorithm, but i know SOF is full of geeks, if someone knows how WhatsApp stops these kind of issues please share, otherwise i will be still glad to know about the advice and ideas that you guys have in your mind for the best security practices.
How banking, paypal etc and messaging apps including WhatsApp works in that scenario and how they stop the issue that i described above?
Important:
I am not going to reverse engineer the WhatsApp, i am just creating a server and fighting with this issue to be solved to secure my server and only accept request from my app but stop requests from unauthorized/fake apps.
Thanks & respect to all in advance who will contribute.
There is no way to prevent malicious reverse-engineering, resulting in a fake app pretending to be the real thing. While you are working on your server, you need to do defensive programming, that is, your server shouldn't assume that the request was sent via the app. So, if you protect your server against all kinds of malicious and deliberate misuses, then your server is safe.
However, that's easier said than done, because your project is developed by a finite amount of people and - if it becomes successful then - the audience contains a swarm of smart bad people.
You will therefore need to detect a subset of features that you need to absolutely protect against misuses and prioritize testing and improving those, by thinking with the mind of a fictional hacker, who would like to either gain unearned profits or do harm to your project. Schizophrenic, I know, but you need to do that on the server. You also need to improve the security of less than critical features, but at a lower priority and log the requests you get, so if SHTF, then you will have at least a chance to deduce what caused it and how.
If the phone app is in your hands as well, then you might implement some additional authentication for each version, like generating a version token for each user that downloads your app. Since the version token generator algorithm would not be in the hands of hackers, they would have to solve that on a per user basis, which is extremely laborius to solve this for several users if done by hand and if they work it out in a way to make it automatic, their solution would be viable only for a version.
So, there is no 100% accuracy in this area, but you can make life very hard and miserable for people payed to hack through your application.
I am working on an embedded system that should support SNMPv3, and I am wondering how to let the user add new USM?
Is it reasonable to let the user add it by SNMP? by HTTPS?
Thanks
Avner
Depends on where you are aiming at with your product:
There are users out there that will only expect to receive some traps from your SNMPv3 device - Those users might not necessarily have access to tooling allowing them to add users via SNMP (or don't want to be bothered with having to install and operate free tooling).
Whether it makes sense to implement a user administration frontpage using HTTPS strongly depends on the amount of muscle your platform has. To me, that sounds a bit heavy-weight.
Most SNMPv3 devices I have come across so far had a simple ssh command-line-based interface for user management, so I would expect that is common practice in the market. Remember, adding users is a one-time activity in most environments.
What you should and must allow in any case is changing users' encryption and authentication keys using the USM MIB - The whole SNMPv3 security concept will cease to be of any value when keys cannot be frequently (ideally, in an automated way) changed.
I've been working on a web app in Clojure as a side project, and I'm trying to figure out how to do user authentication and autherization. From the googling I've done, I heard about sandbar, but after reading the two blogposts on sandbar (Part 1, Part 2), I left with more questions than answers. I've looked at the source code for 4clojure, and from what I can tell, they roll their own, the problem is that the code's not commented very well, if at all. I'm thinking I need to roll my own system and use either sandbar or noir.session to pass user information around. Could someone please point me in the right direction? I feel like I'm missing something simple.
Chas Emerick's Friend library is now available. It's still relatively new, but looks promising and quite well documented.
I had a look at the 4clojure login code and I think it is pretty clear how the implementation works. Basically it is the traditional HTTP authentication. Post user/pwd in form to a URL, check username and password and update the session with the user info that can be used for further requests to check whether this session is for a valid logged in user.
This is how most of the web app authentication works. Now this is "what to do" part of the situation, for "how to do" you can implement it your self using "primitive" features provided by the web framework or probably use some middle-ware that does this for you along with providing some hooks to customize the implementation a bit.
For authentication, apart from the obvious "rolling your own", I found https://github.com/mattrepl/clj-oauth to work well if you want to use OAUTH (e.g. via Twitter). Once you've acquired user information, storing it in some sort of session object (via ring-middleware-session or similar abstractions) seems to be the obvious thing to do.
For authorization, the way described in the blog post you linked to - wrapping certain routes with an authorization middleware (or whatever abstraction your preferred web stack offers - e.g. pre-route in Noir) works well.
There's also an alternative to Friend called Buddy.
What is the difference with Friend?
Buddy authorization/authentication facilities are more low level and less opinionated that friend and allow build over them easy other high level abstractions. Technically, friend abstraction can be build on top of buddy
This question is an open question since it's not bound to a programming language:
Is it a bad idea to provide users an auto-login feature? Why?
I've been reading a couple of papers arguing that auto-login feature on web development leads to many user having trouble with "hijacked" accounts. However, I would like to read a real answer/comment from someone with experience on this matter.
Well, I think it totally depends on the audience which is consuming the services you are providing.
If you are in an intranet environment, then it is a good idea to enable auto login features. Provides more luxury to the users. But still you must check in the background the application access level for each particular user.
In an internet environment you have much less control - more likely to say no control - of who is going to use the application. Therefore there you should have an authentication mechanism in place and do not provide any auto-login features except through cookies.
HTH