You cannot use the same key and IV for more than one vector (with the most AES modes of operation). The only AES mode of operation which is (somewhat) resistant for IV reuse is SIV.
For usual modes of operation like CBC, CTR, GCM, etc. reuse of Key+IV pair is a bad mistake. It is important to acknowledge that there are further requirements for selecting IV in various modes. (Note: For comparing modes of operation, you may want to read: http://www.cs.ucdavis.edu/~rogaway/papers/modes.pdf.)
You maybe should consider using random IVs and storing the IV with vector of other data you store? However, some modes of operation, including CTR and GCM, have little requirements beyond IV being unique. Thus it may be possible to use record id as a portion of IV (initial counter) in one of these modes.
BTW, overall, the whole idea of storing login & password for other sites in web app is not necessarily very good idea from security perspective. It is hard to store the materials so that the data of different users is kept separated.
Things you may want to consider:
- How materials of different users are protected from the other users?
- Be careful that no user can e.g. indicate record id of other user
- Does somebody running this service have access to all the secured login & passwords information of the users of this service?
- Do you want authenticated encryption (GCM, CCM, SIV) or confidentiality only (CBC, CTR)
- Do not use ECB mode for passwords or login information
- Encrypting passwords and login information: it may be bad thing to reveal the length of login and/or password. This alone can be important hint. Maybe pad the materials to constant length?
And... A lot more. (I just wrote a few items here as an example of things to consider. What you're designing is kind of complex to get functioning somewhat securely.)