Tag Info

Hot answers tagged

28

As Phil stated, you can still use the card using its number (as you would do on-line). Also, some ATM machine won't accept the card if not able to read the magnetic strip. The best thing is to use a credit card: in that case you can block the payment and get a refund.


23

Yes, you can. On some places you can find a device called demagnetizer. Just run your card over it (or over a very strong magnet), and the magnetic track will be corrupted and you will only be able to use the chip part of the card.


18

OpenID is a protocol for authentication while OAuth is for authorization. Authentication is about making sure that the guy you are talking to is indeed who he claims to be. Authorization is about deciding what that guy should be allowed to do. In OpenID, authentication is delegated: server A wants to authenticate user U, but U's credentials (e.g. U's name ...


14

Embossed letters are still present on CC to allow to quickly carbon-copy (literally) the card on paper. That's in the (very) old days, but still allowed today, and it will count as PRESENTIAL. Magnetic strip is still there because half of the CC readers still work that way. ATM and TPV outside USA and UE are still missing the chip reader, and even inside ...


10

NOPASSWD doesn't have a major impact on security. Its most obvious effect is to provide protection when the user left his workstation unattended: an attacker with physical access to his workstation can then extract data, perform actions and plant malware with the user's permissions, but not elevate his access to root. This protection is of limited use ...


10

YES, but there is a big chance that an (internally chip-capable) ATM (depending on region) will reject the card! The most common 2 problems for an ATM (including chip-capable) to reject a card are: a dirty or scratched magstripe (as shown in spork's answer) an erased or mangled (=invalid) magstripe by exposure to magnets or EMP (they need to emit ...


8

Claims are a method of providing information about a user, and roles are a description of a user by way of which roles they belong. Claims are generally more useful because they can contain arbitrary data -- including role membership information. E.g. whatever is useful for the given application. Claim Based identities are more useful, but tend to be ...


7

OpenID connect will give you an access token plus an id token. The id token is a JWT and contains information about the authenticated user. It is signed by the identity provider and can be read and verified without accessing the identity provider. In addition, OpenID connect standardizes quite a couple things that oauth2 leaves up to choice. for instance ...


7

Don't do this, it will not work in ATM machines in my experience. I've had to get a new debit card mailed in last month because there was a little scratch out of the magnetic strip, although I had not noticed and had used it for daily chip-only and wireless transactions. It wouldn't work in any (Dutch) ATM machine afterwards (I tried my own bank's and ...


6

Disclaimer: I work for Axiomatics, the leading ABAC/XACML vendor. I am glad to hear you are sold on the philosophy of ABAC. If you haven't already done so, do check out the following resources (I'll spare you commercial links): NIST ABAC project page and report. OASIS' A brief introduction to XACML A quick intro to ABAC with XACML. Gerry Gebel's blog ...


6

There are two specific cases why you don't want passwordless sudo: This is a defense mechanism against malicious users who gain access to an administrative account. This can either be through exploitation or due to an admin leaving his workstation unattended without locking his session. Having to re-issue the password when using sudo gives impulsive users ...


5

As @SteveS said, RBAC is an authorization model whereas claims are a way of providing information about a user. It generalizes the notion of a role. In the past identity servers would simply provide applications the username and the list of roles/groups. Claims generalize this such that any user attribute can be passed on to the consuming application. The ...


5

How can you know who you authorise if you haven't authenticated? Authentication always comes first, except when everyone is authorised or noone is authorised. Edit: seems like you have two questions now :) 1) You were refused most likely because there is an access control policy that prevents your own original UID from performing an operation on the UID of ...


4

OAuth provides only and should only provides authorization using an access token. OpenID connect is built on OAuth 2 in order to provide user authentication information. But will not provide you a more robust implementation than OAuth (since it uses OAuth and add some extra interactions with a OpenID provider). OpenID Connect 1.0 is a simple identity ...


4

First things first: you are not using the correct terminology. This may be problematic if you are looking for documentation. What you call "authorization" is what the rest of the world calls "authentication". What you call "authentication" is what the rest of the world calls "session management". Authentication is about making sure that whoever is at the ...


4

I agree with both answers given thus far by Thomas Pornin and Steve DL. Authorization always comes after authentication since authorization is the act of looking at a given user's claims and determining whether the user can do what they are trying to do based on those claims and based on the authorization policies in place. I would like to broaden the ...


4

A claim is somewhat more arbitrary than a permission. A claim is 'blue eyes' whereas 'AddPerson' is a permission. It is an assertion from the identity provider that a given characteristic (or more accurately, an attribute) about the identity is true. You can determine permission based on claim or characteristic because 'all blue-eyed individuals can do xyz' ...


4

Your problem is a problem of authorization. SSL has nothing to do with your problem. While you must use SSL to protect your data from leaking and tampering, it will not help in any way to solve your authorization problems. Encrypting the parameters is insufficient. It will keep the common user from tampering with the parameters, but it will not stop any ...


3

The problem with this is that in current practice, e-mail is not really a very secure channel to send this sort of information. There isn't much of a way around this, short of convincing the overwhelming mass of humanity to drastically change its e-mail habits. That's probably never going to happen, so we have to live with it as best we can. If an ...


3

Using the same key for two distinct algorithms incurs the risk of interactions. An extreme example is when you use both AES/CBC for encryption and CBC-MAC as MAC algorithm: if you use the same key for both, then it is pretty obvious that the MAC can be trivially worked around. For AES/CBC + HMAC, the gut feeling of most cryptographers is that the two ...


3

OpenID and OpenID Connect are both for authentication, not for authorization. The two activities are distinct. OpenID Connect is in fact OAuth (an authorization protocol) which is turned (abused) into an authentication protocol. More explanations in this answer. To some extent you can mix authentication and authorization, but that's a source of confusion. ...


3

ABAC and CBAC are practically the same thing. Microsoft doesn't call things attributes, but refers to them as claims because attributes tend to be associated with SAML whereas claims are mostly protocol agnostic. XACML is a model/implementation that exposes ABAC, whereas there isn't any concrete CBAC model or implementation -- not from Microsoft anyway. ...


3

Authentication is about identifying who is issuing the command, and making sure that the caller is really that person/system. Authorization occurs necessarily after, since it is about deciding whether the duly authenticated requester should be allowed to proceed or not. In your case with a su command, there are two authentication/authorization. Suppose that ...


2

You can use the TLS/SSL protocol which can provide data confidentiality and data integrity. Combined with HTTP, this gives us HTTPS, which seems to be what you're looking for.


2

Re: tokens Just use a long random string as the token. You can make it exactly as long as you want to. Why would you "encrypt" the user ID to use in the token itself? (Or am I misunderstanding something?) You can optionally also store the user IP and token expiration in the token itself, but these could just as well be in separate DB fields, if you're ...


2

I think RFC 2616 is quite clear: 10.4.4 403 Forbidden The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the ...


2

Attributes are claims. A claim is simply a statement by someone/something that a user has a given attribute. That someone is the issuer which could be an IdP or an internal bit of logic that gets data from the database. This gives you way more flexibility in how you design your systems as you can specify that a given task will always require a user with a ...


2

CBAC (claims-based access control) and ABAC (attribute-based access control) are essentially the same whereby a claim is an asserted "attribute". For instance, you take an attribute from Active Directory and turn it into a claim. However, there are a few issues with CBAC: first of all, it is a Microsoft-specific term, not a model per se like ABAC or RBAC. ...


2

Well there are a couple options here. The first is to reverse it such that your user has a collection of claims that define which projects they have access to: Claims: Project: 123 Project: 124 Project: 125 Project: 129 This could be unmanageable depending on how often the projects are created and the number of projects per user as you'd have to refresh ...


2

Many people still visit this so here's a very simple diagram to explain it Courtesy Wikipedia



Only top voted, non community-wiki answers of a minimum length are eligible