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.


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 ...


11

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

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 ...


7

Technically you can store the access token in your database, and use it for API calls until it expires. It might be more trouble than its worth, though. For one thing, as Jonathan notes in his comment above, now you have to worry about securing your database and the data in it - these tokens give access to some fairly privileged information about your ...


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 ...


5

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

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

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 ...


4

Since the author mentions his product is like Roundcube or Squirelmail.. I know how Roundcube works. Well, Roundcube's webmail DOES NOT have it's own method for logging in users. What I mean is that there is no database which stores anything about the user. Roundcubes takes the credentials user provided and puts them straight in imap_open(). If it ...


4

Encryption is used to provide confidentiality of data that may or will be accessed by an untrusted entity. Access control is used to limit or otherwise control an entity's access to an object. Asking "when do we use them" is an open question. Access controls can be anything from a padlock on a gate to a permission set on a filesystem. They can be simple or ...


3

To ensure only the user has the key for his IMAP-Account, you can save the login credentials in your session symmetrically encrypted by a key, that is stored in a cookie. So the user can unlock the login credentials with his cookie, without that the webserver can't login. Of course you have to ensure that all occurrences of the credentials are overwritten ...


3

I think there is some confusion about the access token and how it is used which can cause a security problem. It is correct that the tokens can be a security risk, but this depends on the information you are asking for from the service. A friends list is more information than first and last name for instance, but that information is not as vital as personal ...


3

There were other (non tape-related) types of copy-protection as well. I remember one game in particular called ACE that had the Lenslok copy-protection: https://en.wikipedia.org/wiki/Lenslok From Wikipedia: "The Lenslok device was essentially a row of prisms arranged vertically in a plastic holder. Before the game started, a two-letter code was displayed on ...


3

I have seen systems that filter by a list of allowed IP addresses first, so in order to even attempt to use an authentication method you have to be coming from a specified IP address or range. This is similar to what you are describing. But in general, authorization refers to deciding what an authenticated user can do, and so logically comes after the ...


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 ...


3

Encryption mechanisms can be used to achieve specific outcomes: Making some data illegible, with the ability for specific individuals to retransform it into a legible format later: this can be used to implement confidentiality within some technical limitations Providing an authentic signature related to a specific blob of data: this can be used to provide ...


2

There's no good way to restrict accounts based on network interface in Linux (by the time a packet reaches a layer that understands the concept of "account", it's forgotten which interface it came in on). However, there are two easy ways to restrict access to an application based on which interface is used: At the OS level, the iptables firewall has ...


2

If you live in an area where no ATM and other cash terminal needs the magnetic strip, you can use a strong magnet to scramble the magnet strip. I personally have done this using a recycled neodymium magnet out of a decommissioned hard drive. Note: never put your debit card in a microwave if you intend to use it afterwards.


2

Certificates establish authentication (tying a person to an identity), which is the wrong approach to limit access to b.example.com - a user is still themselves on both sites, and all authentication's concerned with is having them prove their identity. Limiting access is authorization, which you should do on your end by actually checking the ID contained in ...


2

The registrar verifies the identity of the user (in a comment you said that the user is not anonymous towards the registrar). Identification means that each user has some kind of unique identifier. That could be their social security number, their real name + birthday + birthplace or something like that. The registrar uses a cryptographically secure hash ...


2

Protecting the root account makes cleanup much easier: if an attacker can't tamper with the kernel or most of the programs, it's much harder to hide malicious code. It also means they can't tamper with the antivirus and other protection systems.


2

What I would say about the options that you outline is that HTTP Auth with SSL is a simpler but less flexible option and Oauth2 is more complex but has more flexibility in what you can achieve with it. One example, as you've noted in your ASCII art diagram, with OAuth2 it is possible to create a token which can be used in place of the password to ...


2

In many cases the merchant can check the amount before shipping the item. However many payment gateways implement a checksum value that is hashed with a secret key and if the hash don't match the value the transaction is aborted. There are several flaws with this approach, I gave a presentation at blackhat asia last year that illustrate some of them. You can ...


2

To quote directly: Only use inbuilt session management. Store secondary SSO / framework / custom session identifiers in native session object – do not send as additional headers or cookies. What this is saying is that, if you've got a secondary system which doesn't/can't use inbuilt sessions, you shouldn't send that second session token as a ...


1

You can achieve your goals with two methods: offload logic into servers controlled by you. Lots of games do this already. obfuscate your code. You can use XFuscator, for example. However, with 2, its impossible to be 100% secure. Preventing people from actually running your code by themselfes and not a server is actually quite impossible.


1

ive been thinking about this for a bit due to the fact that you should never store user passwords in plaintext. so I have came up with a possible solution for you. When a user signs up for a new 'service' to their account (e.g. they add gmail or yahoo, etc. ) what you are going to have to do is: Ask the user for their site password again (and validate ...


1

Look into the process of OAuth for client-side applications. Your OAuth flow should look something like this: User logs in Your API returns an access token for that user Your desktop application stores the user token Future requests send the token, and the API uses it to authenticate the user You cannot realistically protect a global secret key in your ...


1

The OTP should integrate with your RADIUS server. I guess you are using NPS? The SafeNet Authentication Manager integrates with NPS and you can use different kind of OTP tokens (preseeded and seedable tokens). You can seed the eTokenNG OTP, i.e. you write the secrets on the tokens yourself.



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