Search Results

Search found 3 results on 1 pages for 'myron'.

Page 1/1 | 1 

• How to detect hidden field tampering?

  - by Myron

  On a form of my web app, I've got a hidden field that I need to protect from tampering for security reasons. I'm trying to come up with a solution whereby I can detect if the value of the hidden field has been changed, and react appropriately (i.e. with a generic "Something went wrong, please try again" error message). The solution should be secure enough that brute force attacks are infeasible. I've got a basic solution that I think will work, but I'm not security expert and I may be totally missing something here. My idea is to render two hidden inputs: one named "important_value", containing the value I need to protect, and one named "important_value_hash" containing the SHA hash of the important value concatenated with a constant long random string (i.e. the same string will be used every time). When the form is submitted, the server will re-compute the SHA hash, and compare against the submitted value of important_value_hash. If they are not the same, the important_value has been tampered with. I could also concatenate additional values with the SHA's input string (maybe the user's IP address?), but I don't know if that really gains me anything. Will this be secure? Anyone have any insight into how it might be broken, and what could/should be done to improve it? Thanks!

  Read the article

• Ruby Gems Either/Or Dependency?

  - by Myron

  My VCR gem currently depends on FakeWeb. I have it declared as a dependency in my gemspec. I'm working with the auther of WebMock (a library that provides similar functionality to FakeWeb) to get VCR to work with WebMock as well, so that users of VCR could use either FakeWeb or WebMock as the http stubbing library. When it comes time to release the next version of VCR, I'm not sure of the best way to handle these dependencies. VCR will depend on either WebMock, or FakeWeb (but doesn't need both), and will have certain version requirements for both. I could add both as dependencies to my gemspec, but when you use bundler, it bundles all gem dependencies--so both FakeWeb and Webmock will get bundled with the application. I've been thinking that maybe I won't declare either gem as a dependency, and check for the presence of either library at run-time (along with checking the version), and give the user a helpful error message if neither is present at a supported version. But I'm not really sure I like this approach either. Does anyone have a suggestion for the best way to handle an either/or gem dependency? Thanks!

  Read the article

• Authenticating users in iPhone app

  - by Myron

  I'm developing an HTTP api for our web application. Initially, the primary consumer of the API will be an iPhone app we're developing, but I'm designing this with future uses in mind (such as mobile apps for other platforms). I'm trying to decide on the best way to authenticate users so they can access their accounts from the iPhone. I've got a design that I think works well, but I'm no security expert, so I figured it would be good to ask for feedback here. The design of the user authentication has 3 primary goals: Good user experience: We want to allow users to enter their credentials once, and remain logged in indefinitely, until they explicitly log out. I would have considered OAuth if not for the fact that the experience from an iPhone app is pretty awful, from what I've heard (i.e. it launches the login form in Safari, then tells the user to return to the app when authentication succeeds). No need to store the user creds with the app: I always hate the idea of having the user's password stored in either plain text or symmetrically encrypted anywhere, so I don't want the app to have to store the password to pass it to the API for future API requests. Security: We definitely don't need the intense security of a banking app, but I'd obviously like this to be secure. Overall, the API is REST-inspired (i.e. treating URLs as resources, and using the HTTP methods and status codes semantically). Each request to the API must include two custom HTTP headers: an API Key (unique to each client app) and a unique device ID. The API requires all requests to be made using HTTPS, so that the headers and body are encrypted. My plan is to have an api_sessions table in my database. It has a unique constraint on the API key and unique device ID (so that a device may only be logged into a single user account through a given app) as well as a foreign key to the users table. The API will have a login endpoint, which receives the username/password and, if they match an account, logs the user in, creating an api_sessions record for the given API key and device id. Future API requests will look up the api_session using the API key and device id, and, if a record is found, treat the request as being logged in under the user account referenced by the api_session record. There will also be a logout API endpoint, which deletes the record from the api_sessions table. Does anyone see any obvious security holes in this?

  Read the article

1