Patent Description:
In order to perform various tasks, for example, accounting or other financial tasks, for users in a client-server relationship, one may desire to collect user data from a large number of users. Collection of user data, especially sensitive financial data, may have many problems, however. For example, for certain kinds of data, a user associated with the data may need to provide credentials, such as a username and password, to a data source. To collect such data in the quantities needed to perform relevant tasks for the user, automation of data collection is required. However, users may be unwilling to provide credentials to a data collector to enable automation. Further, even if users agree to share credentials with a data collector, the data collector must thereafter take significant precautions to store the credentials safely, which can be prohibitively costly. Further still, data sources implementing Multi-Factor Authorization require additional input from users, preventing automation of such data sources using current data collection systems. Therefore, systems and methods are needed which allow a data collector to automate the collection of data accessed using user credentials, without obtaining or storing the user credentials. <CIT> relates to protection of application passwords using a secure proxy.

According to a first aspect, there is provided a method for entering user credentials through a proxy application, comprising: receiving, at a user device, a request for user data; receiving, by the user device, request data having at least one dummy entry from an aggregation system; injecting, by a credential injector of the user device, user credentials stored by the proxy application on the user device into the request data, wherein when injected the user credentials cause the at least one dummy entry of the request data to be replaced; transmitting, by the user device, the request data to a remote data source associated with the request data; receiving, at the user device, user data from the remote data source; and transmitting, by the user device, the user data to the aggregation system, wherein the aggregation system does not store user credentials associated with the user device.

According to a second aspect, there is provided a user device including: a processor; and a memory including computer readable instructions, wherein the processor is configured to, based on execution of the computer readable instructions: receive, at the user device, a request for user data; receive request data having at least one dummy entry from an aggregation system; inject user credentials stored on the user device into the request data, wherein when injected the user credentials cause the at least one dummy entry of the request data to be replaced; transmit the request data to a remote data source associated with the request data; receive user data from the remote data source; and transmit the user data to the aggregation system, wherein the aggregation system does not store user credentials associated with the user device.

Aspects of the present disclosure provide apparatuses, methods, processing systems, and computer readable mediums for entering user credentials using a proxy service.

Current data collection techniques rely on obtaining and storing user credentials for each user whose data will be collected. However, these techniques have several shortcomings, including user unwillingness to share credentials and the cost of steps needed to ensure safety of stored credentials. Further, Multi-Factor Authentication (MFA) techniques frequently require manual intervention to proceed, limiting the ability to automatically collect data from data sources employing MFA techniques. Further still, some data sources may attempt to prevent Denial of Service (DoS) attacks by blocking multiple requests from a single source, and a data collector attempting to collect data may be blocked by DoS preventative measures.

To avoid the problems and limitations of existing data collection techniques, provided herein are systems and methods for entering user credentials to a data source using a proxy service. In particular, by using a proxy application executing on a user device, an aggregation system can make use of user credentials stored on the user device without directly storing the user credentials at the aggregation system. To do so, the aggregation system initiates a data transfer by using a cloud service to send a push notification to the user device.

In response to the push notification, the proxy application identifies one or more data sources corresponding to the push notification and requests, from the aggregation system, one request files that can be used to obtain data from the data sources. The proxy application can then inject the user credentials into a request file and transmit the request file to a data source, receiving the requested user data in response. The user data can then be encrypted and transmitted to the aggregation system, where the user data can be added to a repository of user data for later use.

For example, consider an aggregation system used to collect user financial data. Such a system may refresh stored data periodically, such as every day at a given time. To do so, the aggregation system may initiate push requests to a plurality of user devices, such as mobile devices simultaneously. A push request (or push notification) is a transmission from a server to a client initiated by the server rather than by the client. That is, a push request does not require a prior connection with a user device to be transmitted.

For a particular mobile device, the mobile device may determine to obtain, based on the push request, user data of a particular financial instruction available via a web server of the financial institution. To do so, the mobile device establishes a connection with the aggregation system and obtains from the aggregation system a HyperText Transfer Protocol (HTTP) request file formatted to be compatible with the web server. The mobile device then injects user credentials stored for a user of the mobile device into the HTTP request file and transmits the HTTP request file to the web server. Then, an HTTP response file from the web server may be received, which includes the requested user data. The mobile device then encrypts the HTTP response file and transmits the HTTP response file to the aggregation system, which can thereafter extract user data from the HTTP response file for storage.

Use of the methods and systems described herein has several advantages compared to existing data collection techniques. For example, using proxy entry of credentials obviates the need for an aggregation system to store user credentials, saving the cost of storage as well as insuring the safe storage of the user credentials. Further, using proxy entry of credentials allows for the automatic collection of data from data sources employing certain MFA techniques, expanding the number of data sources where collection can be automated. Further still, because requests for data originate from a plurality of user devices rather than from the aggregation system, using proxy entry of credentials allows for the automatic collection of data from data sources employing DoS attack prevention measures. Users also have greater control over data collection in a proxy system For example, in contrast with existing systems, users of a system using proxy entry of credentials may be able to change collection settings for their own data, such as by redacting certain information or altering collection times.

<FIG> depicts a computing environment <NUM> for aggregating user data using proxy entry of credentials. Computing environment <NUM> includes aggregation system <NUM>, user data repository <NUM>, cloud service <NUM>, user device <NUM> and data source <NUM>. For simplicity, a single user device and a single data source are shown, but in general, computing environments for aggregating user data may collect data from a plurality of data sources via a plurality of user devices.

Aggregation system <NUM> is a computing device including at least a processor and a memory (not shown). Aggregation system <NUM> is used to collect user data, such as from data source <NUM>, from a plurality of users, and store the collected user data in user data repository <NUM>. Although shown as a single device, in other examples aggregation system <NUM> may be a plurality of computing devices such as a cloud computing system or other distributed computing system.

Aggregation system <NUM> includes proxy interface <NUM>, a module of aggregation system <NUM> used to communicate with user device <NUM>. In other examples proxy interface <NUM> may be a separate device from aggregation system <NUM>, such as a publically available server that can be accessed by user device <NUM>. In such an example, proxy interface <NUM> may transmit messages from user device <NUM> to aggregation system <NUM>, and messages from aggregation system <NUM> to user device <NUM>.

Cloud service <NUM> is a service used to transmit push notifications to user devices, such as user device <NUM>. For example, cloud service <NUM> may be a third party service such as Google CM®, iCloud Kit® or Amazon Web Services SNS®. Using such a service, aggregation system <NUM> can initiate a data request from user device <NUM> without first opening a channel of communication with user device <NUM>. Aggregation system <NUM> may be capable of opening a channel of communication with user device <NUM> in some cases, although in many cases the networking and resource costs of simultaneously opening communication with a large number of user devices my be prohibitively expensive. For example, if aggregation system <NUM> aggregates data for several thousand user devices, it may be impractical for aggregation system <NUM> to simultaneously communicate with all user devices without significant upgrades to the components and bandwidth available to aggregation system <NUM>. In general, aggregation system <NUM> may request for cloud service <NUM> to transmit push notifications to one or more user devices, including user device <NUM>.

User device <NUM> is a computing device including a processor and memory (not shown). In some examples, user device <NUM> may be a cellular phone or other mobile device. User device <NUM> includes proxy application <NUM> and user credentials <NUM>. Proxy application <NUM> is a software routine executing on user device <NUM> used to communicate with aggregation system <NUM> and data source <NUM>. User credentials <NUM> are user credentials of a user of user device <NUM>. In this example, proxy application <NUM> has previously received user credentials <NUM> from the user, although in other examples proxy application <NUM> may prompt the user for entry of user credentials upon determining that no user credentials are stored.

In general, upon receipt of a push notification from cloud service <NUM>, proxy application <NUM> establishes communication with proxy interface <NUM>. For example, communication between proxy application <NUM> and proxy interface <NUM> may take place over a persistent WebSocket connection or an HTTP <NUM> TCP SSL connection. Proxy application <NUM> then requests a request file associated with data source <NUM>, allowing proxy application <NUM> to obtain user data from data source <NUM>. Then, proxy application <NUM> injects user credentials <NUM> into the request file and transmits the request file to data source <NUM>.

Data source <NUM> is a publically accessible computing device used to store user data for a plurality of users. For example, data source <NUM> may be a web server available via HTTP. Data source <NUM> may be available for users to navigate as a web site, that is, as a series of web pages with various entry fields and buttons for navigation, such as entry fields accepting one or more user credentials to access user data for a particular user. Navigation of data source <NUM> may be automated by analysis of HyperText Markup Language (HTML) pages of data source <NUM> to determine an HTTP request file that, when transmitted to data source <NUM>, returns an HTTP response file including user data.

Upon receipt of the request file transmitted by proxy application <NUM>, data source <NUM> returns an HTTP response file that includes the user data requested by aggregation system <NUM>. Proxy application <NUM> then encrypts the response file and transmits the response file to proxy interface <NUM>. Then, aggregation system <NUM> can extract the user data from the response file and store the user data within user data <NUM>.

<FIG> is block diagram of proxy application <NUM> used to enter credentials. As shown, proxy application <NUM> includes request handler <NUM>, credentials injector <NUM>, custom injector <NUM> and response handler <NUM>, which are subroutines of proxy application <NUM> used to perform various tasks.

As described above, proxy application <NUM> initiates communication with aggregation system <NUM>, and receives a request file associated with data source <NUM>. Proxy application <NUM> receives the request file via request handler <NUM>. Request handler <NUM> listens on a communication channel of the user device (for example, a specified port for an HTTP connection) for receipt of the request file. Upon receipt, request handler <NUM> determines if the request file is a first communication file data source <NUM> for this session. If not, the request file likely includes a session cookie, and was encrypted by aggregation system <NUM> before transmission. In such a case, request handler <NUM> uses an encryption key associated with aggregation system <NUM> to decrypt the request file.

After any required decryption, request handler <NUM> passes the request file to credentials injector <NUM>. Upon receipt, credentials injector <NUM> determines if the request file includes dummy credentials that need to be replaced. If so, credentials injector <NUM> determines if proxy application <NUM> has stored user credentials for data source <NUM>. For example, if data source <NUM> is a website of a financial institution requiring a username and password for login, request handler <NUM> determines if proxy application <NUM> has stored a username and password for a user of the user device.

If credentials injector <NUM> determines there are not user credentials for data source <NUM>, credentials injector <NUM> notifies proxy application <NUM> to prompt the user of the user device for user credentials, for example, this prompting may take place within a user interface of proxy application <NUM><NUM> displayed on a screen of the user device, including one or more entry boxes for the user credentials.

Credentials injector <NUM> identifies dummy credentials within the request file and replaces those dummy credentials with actual user credentials stored by proxy application <NUM>. The dummy credentials may be any string of text within a request file standing in for actual credentials. For example, if the request file is a POST HTTP request, the request file received from aggregation system <NUM> may include various session cookies. Such cookies, when including dummy credentials, may include strings such as "user_login=DUMMYNAME" or "user_password=DUMMYPWORD.

As credentials injector <NUM> is aware of which dummy credentials are used by aggregations system <NUM>, credentials injector <NUM> searches for dummy credentials within the request file to be replaced. Credentials injector <NUM>, as stated, can replace these dummy credentials with the actual credentials. In the example above, this may include replacing the string "DUMMYNAME" with a stored username, and "DUMMYPWORD" with a stored user password. Thus, by, after decrypting the request file, searching through the plaintext of the request file credentials injector <NUM> can identify and replace dummy credentials with actual credentials. In other cases, dummy credentials may appear as input for FORM elements of HTML files or within many other types of transmission files.

In some cases, certain data sources may perform client-side encryption of credentials, especially passwords. In such cases, the injected credentials need to be encrypted with the encryption logic used by the data source before transmission of the request file. Custom injector <NUM> handles credentials encryption for such data sources. In general, after credentials injector <NUM> injects user credentials into the request file, credentials injector <NUM> passes the request file to custom injector <NUM>. Custom injector <NUM> then searches the request file to identify the user credentials requiring encryption, and using the encryption key associated with the data source, replaces the user credentials with encrypted user credentials.

After the user credentials are injected into the request file, request handler <NUM> proceeds to transmit the request file to data source <NUM>. Thereafter, after processing of the request file by data source <NUM>, data source <NUM> returns a response file to proxy application <NUM>. Response handler <NUM> receives the response file. In some cases, the response file includes user data requested by the aggregation system <NUM>. In other cases, one or more additional request files may be transmitted to data source <NUM> before the user data is received, depending on the navigation flow of data source <NUM>. In any case, response handler <NUM> encrypts the response file and transmits the encrypted response file to aggregation system <NUM>.

<FIG> is a call-flow diagram of an example method <NUM> for performing aggregation of data using proxy entry of credentials. Method <NUM> is performed by aggregation system <NUM>, cloud service <NUM>, user device <NUM> and data source <NUM>.

Method <NUM> begins at <NUM>, where aggregation system <NUM> initiates a request for user data using cloud service <NUM>. In general, the request for user data may be performed on a scheduled basis, such as every day at a particular time, weekly, etc. User of cloud service <NUM> allows aggregation system <NUM> to perform a system wide (e.g., with all associated user devices) data request without requiring a prior connection with each and every user device. After aggregation system <NUM> initiates the request, cloud service forwards the request for the user data to user device <NUM> as a push request, at <NUM>. In general, cloud service <NUM> may forward a plurality of push requests to a plurality of other user devices simultaneously.

At <NUM>, in response to the push request, user device <NUM>, through a proxy application associated with aggregation system <NUM>, opens communication with aggregation system <NUM>. Then, aggregation system <NUM> transmits a request file associated with data source <NUM> at <NUM>. In some cases, aggregation system <NUM> may further transmit a configuration file associated with data source <NUM>. Such a configuration file may include details required for communication with data source <NUM>, such as if data source <NUM> performs client-side encryption. The configuration file may also include a uniform resource locator (URL) associated with a login page of data source <NUM>, identifiers of the type and number of credentials required by data source <NUM> and other identifying information of data source <NUM>.

At <NUM>, user device <NUM> injects stored credentials into the request file, replacing dummy credentials within the request file. Then, user device <NUM> transmits the request file with the injected credentials to data source <NUM> at <NUM>. In general, the request file is transmitted to data source <NUM> in the same manner that a browser would transmit request files to data source <NUM>. Thus, data source <NUM> responds to the request file in the same manner that data source <NUM> would respond to a request file from a user interacting with data source <NUM> via a web browser.

At <NUM>, after processing the request file, data source <NUM> transmits a response file to user device <NUM>. The response file may include the user data initially requested by aggregation system <NUM> at <NUM>. After receipt of the response file, at <NUM>, user device <NUM> transmits the response file to aggregation system <NUM>. Thereafter, aggregation system <NUM> may extract user data from the response file, and store the user data in a database. In general, user device <NUM> may encrypt the response file prior to transmission to aggregation system <NUM>.

<FIG> is a flow chart of an example method <NUM> for obtaining user data through a proxy service. Method <NUM> may be performed by an aggregation system, such as aggregation system <NUM> of <FIG>.

Method <NUM> begins at <NUM>, where the aggregation system transmits a request for user data associated with a user device to a cloud server. The cloud server is configured to transmit the request for the user data as a push request to the user device. The cloud server may be a third party service as described above. In general, use of the cloud server may allow the aggregation system to request data from a large number of user devices simultaneously without overburdening the available network resources of the aggregation system.

At <NUM> the aggregation system receives, from the user device, a request for a request file, wherein the request file is associated with a data source. In general, the request for user data made by the aggregation system at <NUM> is interpreted by the user device to correspond to data stored with a particular data source. The user device thereafter requests from the aggregation system a request file used to communicate with the data source. The request file may have been previously prepared by one or more users of the aggregation system by analyzing request and response files from a typical communication with the data source, such as HTTP files from a communication between the data source and a browser.

At <NUM> the aggregation system transmits the request file to the user device, wherein the request file includes at least one dummy entry. As mentioned, the request file is configured to be used in communication with the data source. However, the request file typically requires one or more user credentials to communicate with the data source. The aggregation system does not have access to these user credentials, so instead, the aggregation system transmits a request file including dummy credentials with the request file where actual credentials may be injected by the user device.

At <NUM>, the aggregation system receives user data associated with the user device from the user device. In general, the user device uses the request file transmitted at <NUM> to communicate with the data source, and receive user data from the data source. In some cases, the user data may be included within a response file transmitted by the data source. In either case, the user device encrypts the user data before transmission to the aggregation system, so the aggregation system typically decrypts the user data upon receipt.

At <NUM>, the aggregation system aggregates the user data with user data associated with at least one other user device. In general, the aggregation system is used to store data for a large number of users in one database. When user data is received for a particular user, the aggregation system stores the user data within the database alongside the other data. The database may thereafter be used for a number of tasks, including calculating data summaries for individual users, or providing large scale tasks across the entire database, such as using the aggregated data for artificial intelligence or machine learning tasks.

In some examples of method <NUM>, the data source is a server storing user data for a plurality of users available via HyperText Transfer Protocol (HTTP). In such examples, the user data is received within an HTTP response file. Further, in such examples in order to aggregate the user the aggregation system may perform the additional steps of: extracting the user data from within the HTTP response file; formatting the user data to a format supported by a user data repository; and storing the user data within the user data repository.

The aggregation system may additionally perform one or more machine learning tasks using the user data in some examples of method <NUM>.

In method <NUM> the aggregation system does not store user credentials associated with the user device, or any user credentials associated with any users. The aggregation system therefore does not need to provide additional security for stored user credentials.

<FIG> is a flow chart of an example method <NUM> for entering user credentials through a proxy. In some examples of method <NUM> may be performed by a user device such as user device <NUM> of <FIG>.

Method <NUM> begins at <NUM>, where the user device receives a push request for user data from a cloud server. In general, the push request is initiated by an aggregation system requesting user data, such as a refresh of stored data for a particular user, from the user device.

At <NUM> the user device receives a request file from the aggregation system. In general, the user device initiates communication with the aggregation system when receiving the push notification. The user device determines, based on the push notification, a data source to obtain the user data from, and requests a quest file from the aggregation system associated with the data source.

At <NUM> the user device injects user credentials stored on the user device into the request file, wherein when injected the user credentials replace at least one dummy entry of the request file. Because the aggregation system does not store user credentials, it relies on the user device to inject the user credentials into the request file. The user device may obtain the user credentials from a user of the user device at the time of injection, if the user credentials are not previously stored on the user device. If the user device has previously stored user credentials for the user and the data source, those stored user credentials are injected into the request file.

At <NUM> the user device transmits the request file to the data source associated with the request file. In some examples of method <NUM>, the data source is a server storing user data for a plurality of users available via HyperText Transfer Protocol.

At <NUM> the user device receives the user data from the data source. In some cases the user data may be received as part of an HTTP response file. Generally, the user device does not attempt to extract the user data from the response file or analyze the user data, instead relying on the aggregation system to perform additional tasks with the user data.

At <NUM> the user device transmits the user data to the aggregation system. In some examples, prior to transmitting the user data to the aggregation system, the user device the user data, to ensure privacy of the user data while in transmitting. After receipt the aggregation system can aggregate the user data with a plurality of other data from other users in order to perform tasks with the aggregated data.

In some examples of method <NUM>, the user device may additionally determine the data source has not previously been accessed by the user device; prompt a user of the user device for entry of the user credentials; and store the user credentials on the user device. These steps may be performed if the user device has not previously stored user credentials for the user. In some such examples, prior to storing the user credentials on the user device, the user device encrypts the user credentials.

In certain cases, the user device may determine, the data source uses client-side encryption, identify an encryption key associated with the data source and encrypt the user credentials within the request file using the encryption key.

In some cases, the data source may be configured to perform Multi-Factor Authentication (MFA). In such cases, the data source may perform additional steps to satisfy the MFA, such as determining a type of MFA used by the data source. For example, the user device may receive a configuration file of the data source from the aggregation system identifying the type of MFA. Then, the user device may prompt the user of the user device for additional input based on the type ofl\;1F A used by the data source. For example, one type of MFA may be to enter answers to security questions. In such examples the user device may prompt the user for the answers, and thereafter store the answers for use on subsequent data requests.

In some cases of method <NUM>, the user device may determine the data source is configured to perform authentication via a one-time password. On possible implementation of one-time passwords is to send a passcode or password to the user via a separate channel, such as to a telephone of the user. In such cases, the user device may then read a short message service (SMS) message sent to the user device. This may be done if the user device is a cell phone or other mobile device capable of receiving SMS messages. After reading the SMS message, the user device transmits at least a portion of the SMS message to the data source. For example, the user device may identify the password or passcode within the SMS message and transmit the extracted password or passcode to the data source.

<FIG> is a block diagram of example user device <NUM>, according to one embodiment. As shown, the machine learning device <NUM> includes, without limitation, a central processing unit (CPU) <NUM>, one or more input/output (I/O) device interfaces <NUM>, which may allow for the connection of various I/O devices <NUM> (e.g., keyboards, displays, mouse devices, pen input, etc.) to machine learning device <NUM>, network interface <NUM>, memory <NUM>, storage <NUM>, and an interconnect <NUM>.

The CPU <NUM> may retrieve and execute programming instructions stored in the memory <NUM>. Similarly, the CPU <NUM> may retrieve and store application data residing in the memory <NUM>. The interconnect <NUM> transmits programming instructions and application data, among the CPU <NUM>, I/O device interface <NUM>, network interface <NUM>, memory <NUM>, and storage <NUM>. The CPU <NUM> is included to be representative of a single CPU, multiple CPUs, a single CPU having multiple processing cores, and the like. The I/O device interface <NUM> may provide an interface for capturing data from one or more input devices integrated into or connected to the machine learning device <NUM>, such as keyboards, mice, touchscreens, and so on. The memory <NUM> may represent a random access memory (RAM), while the storage <NUM> may be a solid state drive, for example. Although shown as a single unit, the storage <NUM> may be a combination of fixed and/or removable storage devices, such as fixed drives, removable memory cards, network attached storage (NAS), or cloud-based storage.

As shown, the memory <NUM> includes request handler <NUM>, credentials injector <NUM> and response handler <NUM>, which are software routines of user device <NUM>. Request handler <NUM>, credentials injector <NUM> and response handler <NUM> may execute based on programming code stored within storage <NUM>.

As shown, the storage <NUM> includes user credentials <NUM>, request file <NUM> and response file <NUM>. In general, user device <NUM> obtains user credentials <NUM> from a user of user device <NUM>. User credentials <NUM> are associated with both the user and a data source. Thereafter, user device <NUM> receives request file <NUM> via request handler <NUM>. Then, credentials injector <NUM> injects user credentials <NUM> into request file <NUM>, replacing dummy entries of request file <NUM>. After injection, request handler <NUM> transmits request file <NUM> to the data source, such as via network interface <NUM>. Then, in response to request file <NUM>, user device receives, via response handler <NUM>, response file <NUM>. Response file <NUM> includes user data of the user. Then, response handler <NUM> encrypts response file <NUM> and transmits response file <NUM> to an aggregation system.

The preceding description is provided to enable any person skilled in the art to practice the various embodiments described herein. The examples discussed herein are not limiting of the scope, applicability, or embodiments set forth in the claims. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments. For example, changes may be made in the function and arrangement of elements discussed without departing from the scope of the disclosure. In addition, the scope of the disclosure is intended to cover such an apparatus or method that is practiced using other structure, functionality, or structure and functionality in addition to, or other than, the various aspects of the disclosure set forth herein.

As an example, "at least one of a, b, or c" is intended to cover a, b, c, a-b, a-c, b-c, and a-b-c, as well as any combination with multiples of the same element (e.g., a-a, a-a-a. , a-a-b, a-a-c, a-b-b, a-c-c, b-b, b-b-b, b-b-c, c-c, and c-c-c or any other ordering of a, b, and c).

Further, the various operations of methods described above may be performed by any suitable means capable of performing the corresponding functions.

A processing system may be implemented with a bus architecture. The bus may link together various circuits including a processor, machine-readable media, and input/output devices, among others. A user interface (e.g., keypad, display, mouse, joystick, etc.) may also be connected to the bus. The bus may also link various other circuits such as timing sources, peripherals, voltage regulators, power management circuits, and other circuit elements that are well known in the art, and therefore, will not be described any further.

Computer-readable media include both computer storage media and communication media, such as any medium that facilitates transfer of a computer program from one place to another. The processor may be responsible for managing the bus and general processing, including the execution of software modules stored on the computer-readable storage media. By way of example, the computer-readable media may include a transmission line, a carrier wave modulated by data, and/or a computer readable storage medium with instructions stored thereon separate from the wireless node, all of which may be accessed by the processor through the bus interface. Alternatively, or in addition, the computer-readable media, or any portion thereof, may be integrated into the processor, such as the case may be with cache and/or general register files.

When referring to the functionality of a software module, it will be understood that such functionality is implemented by the processor when executing instructions from that software module.

Claim 1:
A method for entering user credentials through a proxy application (<NUM>), comprising:
receiving, at a user device (<NUM>), a request for user data;
receiving, by the user device, request data having at least one dummy entry from an aggregation system (<NUM>);
injecting, by a credential injector (<NUM>) of the user device, user credentials stored by the proxy application on the user device into the request data, wherein when injected the user credentials cause the at least one dummy entry of the request data to be replaced;
transmitting, by the user device, the request data to a remote data source (<NUM>) associated with the request data;
receiving, at the user device, user data from the remote data source; and
transmitting, by the user device, the user data to the aggregation system, wherein the aggregation system does not store user credentials associated with the user device.