Why Is It Dangerous to Use AI-Generated Sign-Up Code As-Is?

If you ask a generative AI like ChatGPT or Claude to “create a sign-up feature using an email address and password,” you can get working code in a short amount of time. However, the sign-up process for a real-world service is not just a simple input form and database storage function. It is an operational system that must be designed to include account recovery, password changes, account deletion, a privacy policy, terms of service, administrative privileges, and data retention policies.

In South Korea, in particular, collecting personally identifiable information—such as email addresses, names, mobile phone numbers, and social login identifiers—requires compliance with obligations related to the processing of personal information under the Personal Information Protection Act. AI-generated code is merely a general example, and the legal and operational responsibilities for the actual service remain with the service operator.

Key Principle: AI Can Generate Code, but It Cannot Determine Policy

Code generated by AI tends to focus on whether “the functionality works.” In contrast, an actual service must be able to answer the following questions:

  • What procedure is followed to recover an account when a user forgets their password?
  • Is the current password verified when a user changes it?
  • When a user requests account deletion, which data is deleted and which is retained?
  • Does the Privacy Policy accurately list the actual items collected, their purposes, and retention periods?
  • Is there a contractual basis for suspending users who violate the Terms of Service?
  • Does the admin interface display only the minimum necessary personal information and log access records?

If you simply tell the AI, “Create a sign-up process,” these decisions may be overlooked. Therefore, the operator must first establish the policies and design prompts so that the AI asks questions about items that have not yet been determined.

Basic Security: Never Store Passwords in Plain Text

Even the service operator must not be able to access users’ passwords in plain text. Storing passwords in plain text in a database causes damage to escalate immediately in the event of a data breach.

The secure method is to convert passwords into one-way hashes before storing them. A one-way hash is a conversion method designed to make it practically impossible to restore the original text. Generally, algorithms specifically designed for password storage—such as bcrypt, Argon2id, and PBKDF2—are recommended over fast general-purpose hash functions.

Items to Check When Storing Passwords

Inspection Item Recommended Approach Reason
Stored in plaintext Strictly prohibited All accounts are immediately at risk in the event of a database breach
Hashing Algorithm Use bcrypt, Argon2id, PBKDF2, etc. Increases the cost of brute-force attacks
Salt Usage Apply a unique salt for each user Ensures that even the same password produces a different hash
Operation Cost Setting Set sufficiently high, considering server performance Makes mass guessing attacks more difficult
Logging Do not log passwords or reset tokens Prevents secondary incidents caused by log leaks

Major web frameworks such as Ruby on Rails, Django, and Laravel provide secure password storage features, but simply using the framework’s defaults does not automatically address account recovery, account deletion, or privacy policies.

5 Essential Policies AI Often Overlooks

1. Password Reset Policy

Users will inevitably forget their passwords. Without a password reset feature, administrators must manually process account recovery requests, which increases the risk of identity verification errors or personal data exposure.

Password reset is not simply a matter of “sending a link via email”; it also involves token lifetime, preventing reuse, and ensuring the account’s existence is not disclosed.

Policies to Define

  • Reset link validity period: Set it to a short duration, such as 15 or 30 minutes.
  • Single-use policy: Invalidate a link immediately after it is used once.
  • Token storage method: Consider storing hashed reset tokens in the database rather than storing the plaintext tokens.
  • Preventing Disclosure of Account Existence: Even if a non-existent email address is entered, display the same response, such as “If this email address is registered, we have sent a notification.”
  • Request Limits: Apply rate limiting if excessive reset requests are made from the same email address or IP address.
  • Notifications: Send a notification to the user when their password is changed.

2. Member Information Modification Policy

Members often want to change their email, password, username, notification settings, and more. The minimum viable product (MVP) created by AI often omits the member information modification screen.

In particular, changing a password is a security-sensitive operation. If changes are allowed based solely on the current login session, someone else could take over the account while the user is away from their desk at a café or office.

Policies to Determine

  • Decide whether to require the user to re-enter their current password when changing it.
  • Decide whether to require verification of the new email address when changing an email address.
  • Decide whether to send notifications to both the old and new email addresses after changing the email address.
  • Decide whether to maintain the existing login session or require the user to log in again after changing sensitive information.
  • Decide whether to record the history of member information changes in an audit log.

3. Account Cancellation and Data Deletion Policy

Account cancellation is one of the most critical policies in actual service operations. Users must be able to stop using the service and submit requests related to the deletion or suspension of processing of their personal information. If there is no account termination feature, or if users remain logged in even after termination, both trust and legal risks increase.

However, immediately and permanently deleting all data is not always the right approach. Data subject to legitimate retention requirements—such as for payments, taxes, dispute resolution, and fraud prevention—may need to be retained for a certain period. Therefore, the account termination policy must distinguish between “what to delete, what to anonymize, and what to retain.”

Comparison of Soft Delete and Hard Delete

Category Meaning Advantages Considerations
Hard Delete Physically deletes data from the database Reduces the risk of residual personal information Deleting payment and dispute records may lead to legal and accounting issues
Soft Delete Marks the account as deactivated and blocks login Makes it easy to preserve transaction records, post relationships, and audit trails Personal information may remain, requiring anonymization and access restrictions
Anonymization Converts or removes identifiers (e.g., email, name) to make them difficult to recover Lowers the risk of identification while preserving statistics and transaction records Must verify whether the level of anonymization actually prevents re-identification

Commonly Used Practices

  • Categorize account statuses as active, suspended, or deleted.
  • Immediately prevent users from logging in after account deletion.
  • Delete or anonymize direct identifiers such as email addresses, names, and phone numbers.
  • Payment history, tax-related records, and records of fraud response are retained on a limited basis, with established legal grounds and retention periods.
  • Clearly state in the Privacy Policy which items are retained after account deletion, along with the purpose and duration of retention.

4. Privacy Policy

Even if you collect just an email address, you are required to provide a notice regarding the processing of personal information. The Privacy Policy is not merely “a document we have to throw together”; it is an official document that explains what information the service actually processes and for what purposes.

Copying another site’s Privacy Policy verbatim is risky. If you list information that isn’t actually collected or omit information that is actually collected, the document will not match the service. If using AI, first organize the database fields, sign-up form, social login information, log collection items, and payment integration details, and then have the AI create a draft based on this information.

Key Items to Include in the Privacy Policy

  • Types of personal information collected: Email, name, nickname, social login identifiers, payment information, etc.
  • Purposes of collection and use: User identification, login, customer support, payment processing, prevention of fraudulent use, etc.
  • Retention and usage period: Until account termination; retention periods required by relevant laws and regulations, etc.
  • Destruction procedures and methods: Database deletion, anonymization, backup data destruction cycles, etc.
  • Disclosure to third parties: If data is provided to external parties for advertising, analytics, payment processing, shipping, etc.
  • Outsourcing of Processing: Cloud services, email delivery, payment processing, customer support tools, etc.
  • User Rights and How to Exercise Them: Requests for access, correction, deletion, and suspension of processing, etc.
  • Data Protection Officer or Contact Point

The Difference Between the Privacy Policy and the Terms of Service

Both documents are important but serve different purposes.

Document Key Role Risks if Absent or Inadequate
Privacy Policy Explains why and how personal information is processed Violation of notification and disclosure obligations under the Personal Information Protection Act; loss of user trust
Terms of Service Sets the conditions for service use and the basis for operator actions Lack of grounds to restrict accounts involved in abuse, fraud, profanity, or spam

The Privacy Policy is more like a data processing manual, while the Terms of Service are more like the contractual terms between the user and the service provider. Relying on just one of them is insufficient.

5. Terms of Service and Sanctions Policy

Without Terms of Service, the grounds for account suspension, post deletion, or usage restrictions are weak, even if malicious users abuse the service. In particular, services where users leave a record of their activities—such as communities, marketplaces, SaaS, and content platforms—absolutely require Terms of Service and operational policies.

Key Elements to Include in the Terms of Service

  • Conditions for registration and responsibilities for account management
  • Prohibited activities: illegal acts, fraud, spam, abusive crawling, profanity, infringement of others’ rights, etc.
  • Grounds and procedures for restricting service use
  • Standards for handling posts or user-generated content
  • Terms for payment, refunds, and cancellation, if paid services are offered
  • Notices regarding service changes, suspensions, and termination
  • Limitation of liability and dispute resolution procedures

The sign-up screen must clearly include a consent process for the Privacy Policy and Terms of Service. If optional and mandatory consent items are mixed, users must be able to distinguish between them and select accordingly.

Social Login Doesn’t Eliminate the Need for Policies

Using social login services like Google, Kakao, or Apple reduces the burden of storing passwords and using password recovery features. However, this does not eliminate the need for registration policies.

The following items are still required even when using social login:

  • Specify what information is received from which social login provider.
  • Distinguish between disconnecting a social account and canceling service membership.
  • Include the items collected—such as email addresses, profile pictures, and unique identifiers—in the Privacy Policy.
  • Consent to the service’s own Terms of Service must be obtained separately.
  • Policies regarding account suspension, account termination, and data retention must be established by the service operator.

Security Principles for Creating an Administrator Page

Once you have members, you’ll need an administrator page. However, the administrator page is a high-risk area prone to personal information leaks. Avoid designs that allow “administrators to view all information.”

Administrator Page Checklist

Item Recommended Policy
Access Permissions Grant only the minimum necessary permissions based on administrator roles
Displayed Information Display only necessary information, such as email, registration status, and sanction status
Sensitive Information Do not display passwords, tokens, or full payment information
Sanction Features Record suspension reasons linked to prohibited acts in the Terms of Service
Audit Logs Record who viewed or modified which member information, and when
Administrator Authentication Enforce strong passwords and multi-factor authentication

Best Prompt Structure for AI Requests

When interacting with AI, you should convey “policies” rather than just “features.” Using the following structure can help minimize omissions.

Items to Include in the Prompt

  1. Tech stack: For example, Ruby on Rails, Next.js, Django, Laravel, etc.
  2. Sign-up methods: Email and password, social login, invitation-based sign-up, etc.
  3. Authentication policies: Email verification, login failure limits, session expiration, two-factor authentication requirements
  4. Password Policy: Hashing method, change procedure, reset link expiration
  5. Account Termination Policy: Deletion, anonymization, retained data, whether re-registration is allowed
  6. Legal Documents: Criteria for generating drafts of the Privacy Policy and Terms of Service
  7. Administrator Policies: User Lookup, Suspension, Audit Logs, Least Privilege
  8. Exception Handling: Duplicate email addresses, re-registration of deleted accounts, login attempts from suspended accounts, etc.

Example Prompt

Implement registration and login functionality using an email address and password.
Store passwords as secure one-way hashes; do not store them in plain text.
Ensure that password reset links are valid for only 30 minutes and are discarded after a single use.
Require users to re-enter their current password when changing it.
When a user cancels their membership, immediately block login access; anonymize the email address and name, but design the system to allow payment history to be stored separately, taking into account legal retention requirements.
Based on the database fields being collected, create a list of items to include in the draft Privacy Policy and Terms of Service.
Please include mandatory checkboxes for agreeing to the terms and conditions on the sign-up screen.
For the admin page, follow the principle of least privilege to display only email addresses, sign-up status, and sanction status, and log all queries and changes in the audit log.
Before implementation, please ask me first if there are any policies I haven’t specified that require a decision.

The last sentence—“If there are any policies I haven’t specified that require a decision before implementation, please ask me first”—is very important. Including this sentence ensures that the AI acts not merely as a tool for generating code, but as an assistant planner who identifies any missing policies.

Pre-Deployment Checklist

Before deploying to a live service, verify the following items:

  • Are passwords stored in plain text?
  • Do password reset links have a short expiration period and a one-time use limit?
  • Does the password reset request screen reveal whether the account exists?
  • Does the system require confirmation of the current password when changing it?
  • Is there a verification process for the new email address when changing it?
  • Does the account deletion feature actually exist, and does it block further logins?
  • Are the data categories—deleted, anonymized, and retained—clearly distinguished after account deletion?
  • Does the Privacy Policy match the actual data collected?
  • Do the Terms of Service include prohibited actions and the grounds for account sanctions?
  • Is there a procedure for agreeing to the Terms of Service and Privacy Policy upon sign-up?
  • Is the admin panel designed according to the principle of least privilege?
  • Are logs maintained of administrator access and the history of personal information queries and modifications?
  • Do logs and error-tracking tools contain no passwords, tokens, or sensitive information?
  • If social login is used, are the information received and the disconnection policy reflected in the documentation?

Conclusion

In the age of AI, product development capabilities are not determined solely by the ability to write code quickly. To operate a service in practice, you must decide in advance on authentication security, personal information protection, account termination and data retention, terms of service, administrator privileges, and exception handling.

While AI accelerates implementation, it is up to the operator to determine which policies are safe, legal, and appropriate for the service. When building a sign-up feature, you must first define “what data to collect, how to protect it, when to delete it, and on what grounds to impose sanctions” before asking AI to generate code.