locked
BEST PRACTICE: Use of sessions to store Credit Cards ? RRS feed

  • Question

  • User-973886032 posted

    hi guys 

    I had a debate with a few developers about the heavily uses of sessions. "When processing payments"

    Summary

    We were discussing about storing Credit/Debit cards which cannot be written down to any file or db , so they said sessions are heavily used. Which obviously has its downside 

      Memory/Resource usage

    especially when the project starts to scale to the enterprise level (tens of thousands or millions of hits)

    What do you recommend as a best practice or alternative approach ?

    many thanks

    Ehi

    Tuesday, December 3, 2019 11:22 AM

Answers

  • User765422875 posted

    No, I dont like sessions, but as I said earlier, the developers are using sessions. Hence I am looking for an alternative

    Then you can look into using a distributed cache such as Redis or the Azure Redis service. If you decide to use redis, you need to use a good client library to work with it such as StackExchange.Redis.

    Redis databases can also be secured.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, December 4, 2019 5:27 PM

All replies

  • User475983607 posted

    Credit card numbers are used at the point of purchase and either entered by the user or fetched from a DB.  The later should be PCI compliant.  There's no logical reason to store credit card numbers in Session.

    Tuesday, December 3, 2019 12:01 PM
  • Tuesday, December 3, 2019 12:59 PM
  • User-973886032 posted

    I think you missed the question. We are not trying to store card numbers, I asked about best practices to using sessions, as a developer

    Tuesday, December 3, 2019 1:30 PM
  • User-973886032 posted

    Credit card numbers are used at the point of purchase and either entered by the user or fetched from a DB.  The later should be PCI compliant.  There's no logical reason to store credit card numbers in Session.

    Yes the server is a PCI complaint server, its for a company that has everything in place, but the mode of storing the card details are currently sessions, I asked if there was a better way

    Tuesday, December 3, 2019 1:31 PM
  • User475983607 posted

    Yes the server is a PCI complaint server, its for a company that has everything in place, but the mode of storing the card details are currently sessions, I asked if there was a better way

    I answered this question above.  It seems you are looking for an answer that matches your expectations.

    Session is an ASP.NET state management feature.   In my experience, credit card numbers are entered by the user or fetched from the DB at the point of sale.  There is no logical reason to use Session state management to store this type of information nor is it recommended since Session is global.  HTML form input and DB storage are both alternative forms of state management as explained above.

    Tuesday, December 3, 2019 2:08 PM
  • User-821857111 posted

    the mode of storing the card details are currently sessions, I asked if there was a better way
    Why are you persisting credit card details? How long for? What happens in the event that the memory is reclaimed by the server and the card details are lost?

    Tuesday, December 3, 2019 4:09 PM
  • User-973886032 posted

    Mikesdotnetting

    Why are you persisting credit card details? How long for? What happens in the event that the memory is reclaimed by the server and the card details are lost?

    Spot on !!!

    That was my exact argument with the developers, my company is liaising with another team, who have over 10 years of code which simply persist sessions in IIS, I said it was a poor design and I am researching the way forward, I suggested as variables in a Stored Procedure or clr function in sql server, but at the moment I am researching the way forward

    Tuesday, December 3, 2019 4:13 PM
  • User-821857111 posted

    It still begs the question why you are storing credit card details. You normally store them as a convenience for repeat customers, in which case you would use a database as mgebhard has pointed out. It's difficult to conceive of a reason for temporary storage of the details. If you aren't going to store the details long term, you presumably just post the details to the payment provider and relieve yourselves of the issue, no?

    By the way, Sessions are wiped out when the user closes the browser.

    Tuesday, December 3, 2019 4:45 PM
  • User765422875 posted

    Using Session is a bad idea for this requirement. Session state will persist the information, but it is not secure and only temporary. Be aware that any kind of persistence may be violating the terms of service with the bank or credit agency. Most of them have very strict regulations on what you are allowed to do with this information. Furthermore, any payment application that accepts Visa and MasterCard should be compliant with the PA-DSS (Payment Application Data Security Standard), a global security standard for payment applications.

    Integrating with a 3rd party payment system that has all the built-in security mechanisms is the way to go.

    Refer to the following stackoverflow answer if you can't integrate with a 3rd party payment system.

    Wednesday, December 4, 2019 3:16 PM
  • User-973886032 posted

    Mikesdotnetting

    It still begs the question why you are storing credit card details.

    Its a payment solution (IVR, click to pay, 3d secure etc)

    Mikesdotnetting

    You normally store them as a convenience for repeat customers

    There is a hash value generated by the card processing gateway, which developers are allowed to store in a db, but NOT the card number/details,

    Mikesdotnetting

    By the way, Sessions are wiped out when the user closes the browser.

    Yes I know, hence reason why I asked this question, to find out if there is a better way to persist data without sessions or written down

    Wednesday, December 4, 2019 4:12 PM
  • User-973886032 posted

    Furthermore, any payment application that accepts Visa and MasterCard should be compliant with the PA-DSS (Payment Application Data Security Standard), a global security standard for payment applications.

    Integrating with a 3rd party payment system that has all the built-in security mechanisms is the way to go.

    Yes these are already in place. Its just the choice of storage that seems odd to me, hence I seeking alternatives which people have done

    Wednesday, December 4, 2019 4:14 PM
  • User475983607 posted

    Its just the choice of storage that seems odd to me, hence I seeking alternatives which people have done

    The community has answer this question several times.  Maybe the solution(s) presented by the community do not match the answer you  are looking for?   

    Or perhaps you are asking a more general question like;  "What are the Pros and Cons of InProc Session?"

    Wednesday, December 4, 2019 4:46 PM
  • User765422875 posted

    Ok - Session is not the right choice - use a database if you need to. Also, refer to the stackoverflow answer I linked to in my previous response as to what kind of columns (if SQL) you should use and hashing.

    Wednesday, December 4, 2019 4:57 PM
  • User-973886032 posted

    afrika

    Its just the choice of storage that seems odd to me, hence I seeking alternatives which people have done

    The community has answer this question several times.  Maybe the solution(s) presented by the community do not match the answer you  are looking for?   

    Database inserts or hashing is out of the question, as the Payment gateways TOS demands it must never be written down or inserted. Hence reason I asked if there was another way

    Or perhaps you are asking a more general question like;  "What are the Pros and Cons of InProc Session?"

    No, I dont like sessions, but as I said earlier, the developers are using sessions. Hence I am looking for an alternative

    Ok - Session is not the right choice - use a database if you need to. Also, refer to the stackoverflow answer I linked to in my previous response as to what kind of columns (if SQL) you should use and hashing.

    AS I said above, hashing is out of the questions

    Wednesday, December 4, 2019 5:12 PM
  • User765422875 posted

    No, I dont like sessions, but as I said earlier, the developers are using sessions. Hence I am looking for an alternative

    Then you can look into using a distributed cache such as Redis or the Azure Redis service. If you decide to use redis, you need to use a good client library to work with it such as StackExchange.Redis.

    Redis databases can also be secured.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, December 4, 2019 5:27 PM
  • User753101303 posted

    Hi,

    Knowing for how long you really need this credit card information could help.

    As it seems you don't want a "save card details" feature, I would expect this value to be posted from the user input, used, and forgotten immediately or at worst kept for a short time using https://www.tutorialsteacher.com/mvc/tempdata-in-asp.net-mvc (still uses a session variable but is is cleared when used).

    Edit: More generally I use basically session variables as a browser session lifetime scoped cache that is for small, "private", frequently used values that preferably could be (re)loaded on demand. This way using the session is bascically just an implementation detail.

    Wednesday, December 4, 2019 5:54 PM
  • User475983607 posted

    Hence reason I asked if there was another way

    HTTP has 3 staple persistence mechanisms. 

    • Cookies 
    • URLs
    • HTML Form Fields

    ASP.NET comes with libraries that take advantage of these mechanisms.  

    • Session
    • TempData
    • ViewState
    • Cache
    • Dependency Injection
    • Context
    • Configuration

    Often a key is stored in an HTTP persistence mechanism which is used as an index; Session, TempData, etc.

    There are also external persistence stores like database, distributed cache, and browser based storage. 

    These are your options.  It is up to you to select an option that fits your needs.  Given your requirement it seems HTML form Fields and/or a short lived cache is what you are looking for.

    Wednesday, December 4, 2019 9:33 PM
  • User-1780421697 posted

    You can use Redis as session provider or SQL Server, in case of SQL Server it will have some side effect of performance but it will not consume as much memory resources and it will also solve issue of scalability, In case of radius it will give you great performance. they are available as session state providers.

    As far as security is concerned, if you want additional security then you can use encryption when store data.

    Thursday, December 5, 2019 5:20 AM
  • User-973886032 posted

    Then you can look into using a distributed cache such as Redis or the Azure Redis service. If you decide to use redis, you need to use a good client library to work with it such as StackExchange.Redis.

    Redis databases can also be secured.

    Thank you everyone for the comments/advice. Interestingly, I never heard of redis and its a great way forward

    I am researching into options provided. Many thanks

    Monday, December 9, 2019 12:17 PM
  • User-973886032 posted

    HTTP has 3 staple persistence mechanisms. 

    • Cookies 
    • URLs
    • HTML Form Fields

    ASP.NET comes with libraries that take advantage of these mechanisms.  

    • Session
    • TempData
    • ViewState
    • Cache
    • Dependency Injection
    • Context
    • Configuration

    Often a key is stored in an HTTP persistence mechanism which is used as an index; Session, TempData, etc.

    There are also external persistence stores like database, distributed cache, and browser based storage. 

    These are your options.  It is up to you to select an option that fits your needs.  Given your requirement it seems HTML form Fields and/or a short lived cache is what you are looking for.

    These options as well as others, dont quite hit the nail on the head, But Redis appears to do so

    As I said above, I was asked to consult for a up coming company that processes a lot of payments and connected to the major gateways, Since the law demands they cant store credit or debit cards, redis seems to be a solution. 

    ViewData and the likes, named above, will expire when the scope (ie controller action) is completed, same with sessions, but I am looking into redis. 

    Thank you

    Monday, December 9, 2019 12:21 PM
  • User475983607 posted

    These options as well as others, dont quite hit the nail on the head, But Redis appears to do so

    As I said above, I was asked to consult for a up coming company that processes a lot of payments and connected to the major gateways, Since the law demands they cant store credit or debit cards, redis seems to be a solution. 

    ViewData and the likes, named above, will expire when the scope (ie controller action) is completed, same with sessions, but I am looking into redis. 

    Redis is a global cache.  Redis still requires state to tie the user to the cached credit card item.  

    Monday, December 9, 2019 1:01 PM
  • User-973886032 posted

    Redis is a global cache.  Redis still requires state to tie the user to the cached credit card item.  

    My thoughts are, with key value pairs, we can store the sessionID as the key and the card as the value. As if redis is installed on the local server, it could be dedicated to the card reader business/data object

    Monday, December 9, 2019 1:34 PM
  • User-1780421697 posted

    You can use local redis server or azure redis cache.

    Friday, December 13, 2019 4:59 AM