So I know it's possible to use vm_read_overwrite and vm_write without asking the user to type in their password every single time your app launches.
I have an app that does this. I know you need to sign your application, then a password dialog will be displayed if your app reads/writes another process. You generally type in the root password once and then the app runs as your local user.
My problem is I'm creating a new app, which I signed, but it's not posting the dialog for permission.
Am I missing another step here? Worst case I can copy/paste my existing project, but I'd rather not as it's quite large.
Thanks!
Found it, needed SecTaskAccess set to allowed in Info.plist
http://os-tres.net/blog/2010/02/17/mac-os-x-and-task-for-pid-mach-call/
Related
I'm trying to make a login screen with following properties:
Left pane: button to choose an access database (open file).
as soon as the "connect" button is pressed, the right pane opens with a user/password screen.
The user and password should be checked in the access database users table.
The database is only loaded if correct credentials from inside the file are provided.
So in short:
Is this possible or do i need a separate file to store those credentials and how to load the database in order to access it in my software.
I'm a beginner.
thanks in advance
The trick is you must open the database in order read the credentials. Therefore you need two layers of security.
The good news is MS Access supports this. You can set a password on the database file itself, and then distribute that password with your app in a place where the user can't see.
The bad news is these passwords aren't all that secure. First, securely distributing a credential with your app so it can't be discovered is surprising difficult. In short, it's something you should not be attempting as a beginner. Second, the MS Access password protection feature is not all that strong.
Most systems where security really matters will keep the credentials and most important data on a system they control, usually via a web service.
If you do proceed with the Access database, make sure you understand the correct way to store user passwords... namely that you don't ever store the password itself, but instead only keep a cryptographic hash. When a user logs in, you also hash the attempted password and then compare the hashes.
Apologies for the general nature of this question. Hoping this doesn't get shot down as "too broad", but oh well, here goes:
I'm writing a React Native app that is purely informational (medical information), with a Rails API for the back-end.
The first main question I have is whether its necessary (or a good idea) to use authentication at all. We don't want the user to have to enter any information to use it (username, password, etc). They should just be able to download the app and jump right in to use it and read the information it provides.
However, I'm thinking that I would at least want the API to only respond to someone hitting it from within the React Native app (or not? Is it considered a normal practice to have an API completely exposed in the case of an app like this which is purely information and doesn't have users, like a website?)
Second - at some point we may want to be able to store some simple preferences for that user (I.E., are they a patient or a doctor, so we can tailor the materials based on that / send them to a different home screen when the open the app). Wondering what strategy someone might use to store simple preferences if the user doesn't ever create an account?
I would at least want the API to only respond to someone hitting it
from within the React Native app.
This probably can't be done, as in a mobile app everyone has access to your client secret and can try to reverse engineer your code.
You could make it more difficult by sending a dynamically generated token to your API on the request, for example, a hash based on a time frame, and check if the hash was sent the correct way. Then, you'd have to obfuscate the code in order to make it difficult for someone to reverse engineer it.
Second - at some point we may want to be able to store some simple
preferences for that user (I.E., are they a patient or a doctor, so we
can tailor the materials based on that / send them to a different home
screen when the open the app). Wondering what strategy someone might
use to store simple preferences if the user doesn't ever create an
account?
If you use a Parse Server instance as your backend, you could benefit from the anonymous user functionality. As you're using a Rails API, you could generate a uuid for each installation of the app and save the preferences on your database based on that uuid. If you don't need those preferences stored on your backend, just store any information you need on the device through any abstraction of AsyncStorage.
I really do not need authentication when it comes down to it - there are no users.
I could verify that the data is coming from my app based on a user agent or a hard coded password. SSL should help keep those secret.
But yeah, there would be nothing preventing someone from disassembling the app and getting that information. Great idea by #felipe-martim about generating a dynamic token.
I really just want to prevent basic abuse, and I could deal with that if it ever happened, or protect myself with something like Rack-attack.
And storing user preferences locally should work just fine for local preferences.
Bottom line is that I'll deal with this if I ever need to / the client budget allows for it!
I am well aware of the security implications of this, so much so that I'm betting it doesn't exist, so before you call me crazy, that's why I'm asking.
I got really tired of having only my phone on me and installing a new app/whatever and finding myself needing to suddenly create a new application-specific password on the fly, and having to navigate Google's decidedly non-mobile-friendly security page to do that. I want to create an app of some kind that allows me to generate an application-specific password, whether by text or an Android app itself or something else. As I see it, there are two options here:
Use some Google Account Security API (if it exists) to create the application-specific password
Do scraping-type behavior (with proper credentials, of course) to automate its creation. I really don't want to do this.
Does anyone know (a) if this type of API exists, or (b) if there are any other ways to go about doing this? This app would be published on Github for self-hosting, obviously.
There is no official API to generate application-specific passwords.
I've solved this myself by doing a couple of things:
1) printing out the QR Code for the account that can be scanned by the Authenticator app in order to generate codes. I keep it secured in my desk. This allows me to reformat my phone without needing to turn two-step off each time.
2) use the browser sign-in for my Android device. When adding a Google account to an Android phone, just before the screen where you enter your username and password, click the menu button (or 3 dots on the screen if you have no menu button) and choose Browser sign-in. This allows you to login to an Android device with your username, real password and verification code rather than an application specific password.
This saves me from needing to generate application-specific passwords 95% of the time.
Jay
I wonder if I might disable the keychain dialog that pops up whenever my application wants to access the keychaindata. My app compares a TextField's string with a keychain entry in order to check if the entered Password is correct.
It works fine but it asks for the permission accessing it.
How to avoid this behaviour?
Best regards,
Adrian
Another advice is to code-sign your executable, even on OS X.
If you don't, then the system always asks the user if s/he allows the program to access the keychain when the program is updated, even when your user selected "Allow Always" before. This is because the system can't tell if the so-called updated program is a genuinely updated version.
As written in this Apple document, if you code-sign, the system doesn't ask the user if s/he allows the program to access the keychain when the program is updated, because the system can tell your new version of the app is really the new version of the app, issued by the same programmer.
So, to minimize the number of keychain dialogues, code-sign your app. Yes it's optional on OS X, unlike on iOS, but it has a few advantages.
This is the intended behaviour, so that Users are in control of what apps can access their keychain. If you want to avoid the prompt click "Allow always" on the dialog.
i am currently trying to secure my Objective-c application with a password. What I want is a window(or similiar..) popping up whenever the application is launched. Only if the password is right shall the user be able to use the program.
How to encrypt the string properly? I don't want any user to be able to extract it from the content files. Even though the user should be able to change it once he "logged in".
Thanks in advance.
I am asking for a hint only :)
Whenever you want to store sensitive information such as passwords, use Keychain Services.
You can create an md5-hash of the password and store that in a file. If someone else opens this file and sees the hash, it almost impossible to reformat it back to the original password. Now when the user enters a password in your application, make an other md5 hash from that one, and compare if that hash is the same as you stored in the file.
man 3 md5 for creating md5 hashes on Mac with C code. I don't know any Objective-C wrapper for that, but it should be easy to create it yourself.
Hope it helps,
ief2
EDIT: Keychain Services is indeed the more "standard" solution